On GNU systems stddef.h is shipped with compiler and on NetBSD it's
shipped with the system headers.
I've run into an issue that this caused mismatch between a compiler type
and header type in wchar_t.
cc -fshort-wchar generates code for wchar_t of type 'unsigned short
int', however it was hardcoded for 'int'.
There was a similar bug for wint_t and wchar_t fixed by pooka@ in i386
headers:
https://github.com/NetBSD/src/commit/897353ab7e17a4803b17f262981b5a17ee294937
The same can affect other types such as size_t.
This code demonstrates the issue:
$ cat test.c
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
int
main(int argc, char **argv)
{
wchar_t a = 0;
short unsigned int b = 0;
printf("sizeof(wchar_t)=%zu\n", sizeof(a));
printf("sizeof(short unsigned int)=%zu\n", sizeof(b));
return 0;
}
$ cc -fshort-wchar test.c
$ ./a.out
sizeof(wchar_t)=4
sizeof(short unsigned int)=2
-fshort-wchar
Override the underlying type for "wchar_t" to be "short unsigned
int" instead of the default for the target. This option is useful
for building programs to run under WINE.
Warning: the -fshort-wchar switch causes GCC to generate code that
is not binary compatible with code generated without that switch.
Use it to conform to a non-default application binary interface.
-- gcc(1)
I've detected this issue when attempting to build firmware.
Can we switch all such types in all ports to compiler types whenever
possible? This means that we will pick compiler ideas about:
__PTRDIFF_TYPE__, __SIZE_TYPE__, __WCHAR_TYPE__ and __WINT_TYPE__
whenever accessible. ARM already makes use of all them and we could
expand it to all ports.
These defines are compatible between GCC and Clang.
For now I went locally for a patch fixing short wchar_t in amd64:
http://netbsd.org/~kamil/patch-00078-amd64-wchar-type.txt
Attachment:
signature.asc
Description: OpenPGP digital signature