On 02.02.2019 14:37, Greg Troxel wrote: > Kamil Rytarowski <n54%gmx.com@localhost> writes: > >> On GNU systems stddef.h is shipped with compiler and on NetBSD it's >> shipped with the system headers. > > What do C99 and POSIX say? > > It seems strange for compilers to pick types when they are part of the > system ABI. > I've noted that people from the toolchain LLVM community think that our approach of homwgrown stddef.h is a bug as it shall be shipped by a compiler. I'm not convinced with this, but I think we shall obey types used by a compiler whenever accessible. >> 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'. > > Isn't -fshort-wchar documented to deviate from the system ABI? It can deviate and it does happen on NetBSD, but it's here for building code for cross-abi purposes. In my case we misgenerate EFI firmware when built on NetBSD. Such issues are certainly difficult to track. However for almost 100% of other use-cases there is no ABI conflict. I was already testing for a long time native compiler types in combination with the system ones and it worked until the moment I had to generate code for a custom ABI. > Isn't it > a bug to use it, unless you somehow want that behavior? > -fshort-wchar is here to introduce a feature, not a bug. E.g. Windows uses wchar_t that is 16-bit too. > > Or are you saying that -fshort-wchar is supposed use a fixed type, and > instead the compiler is picking up the system header? > I'm saying that we shall pick a compiler type always and fallback to the default ABI hardcoded in the headers. We were already doing similar switch depending on a compiler ABI explicitly, at least with va_list. In this case I'm proposing to keep a fallback for hardcoded types.
Attachment:
signature.asc
Description: OpenPGP digital signature