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