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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.07.16 at 15:46, <andrew.cooper3@xxxxxxxxxx> 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.
> 
> We cannot expect to use -Wformat and not the compiler provided
> inttypes.h.  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.

Well, it's clearly sub-optimal to use types like "long" or "long long" to
set up our fixed width ones; we would really better make use of
__attribute__((__mode__(...))) here.

Jan


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