Re: Conflict between system and compiler types

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Feb 02, 2019 at 03:08:48PM +0100, Kamil Rytarowski wrote:
 > > What do C99 and POSIX say?

Nothing; both the compiler and the OS are part of the implementation.

 > > 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.

They are wrong -- the system ABI is the OS's responsibility
(including, possibly, compat obligations that the compiler folks don't
know about and shouldn't have to care about) because it's the OS that
provides the libraries that the definitions in the system ABI headers
are supposed to match.

One could argue that a small number of standard headers
(e.g. stdbool.h) refer to nothing that belongs to the OS and can thus
be provided by the compiler; but as these are also all highly stylized
they can and should also be provided by the OS as this avoids a
substantial set of build and integration complications. Having
compiler-supplied headers among the system headers is a Problem as
sson as the system supports more than one compiler.

Note that in any event stddef.h is definitely _not_ among this set of
headers, because wchar_t appears in the signatures of many library
functions, and the compiler is not providing those.

It is still necessary for the compiler and the system to agree on what
type wchar_t is; this is a matter for the compiler's build-time
configury.

In the distant past the linux world wasted a lot of effort because
they'd somehow convinced themselves that providing a gcc-compatible
stdarg.h when the compiler was gcc was UB, which meant they needed to
go to a lot of trouble to build their kernel with -nostdinc (which is
necessary) but still manage to get gcc's stdarg.h. I have no idea if
they ever sorted that out properly.

 > I'm not convinced with this, but I think we shall obey types used by a
 > compiler whenever accessible.

In the case of wchar_t it is probably worse to do that than not,
because if you use this option to change the type of wchar_t and
compile against system headers that adapt to it, you'll get successful
builds and nasal demons at runtime when you link to a libc image that
now doesn't match its headers.

If we wanted to provide an alternate libc build for short wchar_t and
automatically arrange to link it instead of the normal build, then it
would make sense to have the headers adapt... but this seems like a
lot of work and tilting at windmills.

 > > 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.

Surely such firmware should be compiling with -nostdinc...

-- 
David A. Holland
dholland%netbsd.org@localhost