Re: [Xen-devel] [PATCH 1/6] xen/build: Allow the use of C freestanding headers

[Tim Deegan <tim@xxxxxxx>]

At 14:46 +0100 on 13 Jul (1468421211), Andrew Cooper wrote:
> On 22/06/16 14:12, Tim Deegan wrote:
> > At 12:24 +0100 on 22 Jun (1466598248), Andrew Cooper wrote:
> >> The C standard defines two types of conforming implementation; hosted and
> >> freestanding.  A subset of the standard headers are the freestanding 
> >> headers,
> >> requiring no library support at all to use, and therefore usable by Xen.
> >>
> >> Unfortunately, -nostdinc is an overly large switch, and there is no
> >> alternative to only permit inclusion of the freestanding headers.  
> >> Removing it
> >> is unfortunate, as we lose the protection it offers, but anyone who does 
> >> try
> >> to use other parts of the standard library will still fail to link.
> > I'm afraid I don't think this is a good idea:
> >  - Leaving the standard include path around in the Xen build means
> >    that the build may differ based on what (unrelated) libraries are
> >    installed on the build machines.
> >  - There are plenty of ways for an unexpected header to break things
> >    that don't fail at link time, e.g. macros and inlines.
> >  - "Freestanding" headers can bring in quite a lot of unrelated cruft.
> >    See Jan's email about linux/glibc, and I remember seeing similar
> >    things on solaris and *BSD when I tidied up stdarg.h. E.g. looking
> >    at two machines I'm working on today, on one of them,
> >    #include <limits.h> defines __packed, and on the other it does not.
> >
> > Since what we have already works fine for all the compilers we
> > support, I think it ain't broke and we shouldn't fix it.
> 
> Except it is broken.

Broken in theory or actually causing a problem right now?

> We cannot expect to use -Wformat and not the compiler provided
> inttypes.h.

Since we're not using the compiler-provided printf(), I think that
we're on pretty thin ice with -Wformat anyway.  But as long as our
own PRI* macros match our type definitions, all should be well, right?

> The sizes of constructs like "long long" are implementation
> defined, not spec defined.  The compiler is perfectly free to choose
> something which doesn't match our inttypes.h, and we would be in the
> wrong when it fails to compile.

If a compiler we support does that, we can update our integer type
definitions, like we do for attribute annotations, &c.

BTW, I can absolutely see the argument for deferring to the compiler
in C implementation details.  I think that would have to include
removing all the implementation-reserved names from Xen so we don't
clash with compiler headers.

But in practice it seems to be messy enough to be better avoided --
having /usr/include on the search path is pretty silly.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel