Re: [Xen-devel] [PATCH 0/6] xen/build: Use system headers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.06.16 at 14:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/06/16 13:26, Jan Beulich wrote:
>>>>> On 22.06.16 at 13:24, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Make use of C standard freestanding headers, to avoid bugs in our own local
>>> versions of inttypes.h and booleans.
>> While the motivation to do this is certainly a good one, I see possible
>> problems resulting from this. These are best demonstrated by
>> compiling a C file containing just
>>
>> #include <inttypes.h>
>> #include <limits.h>
>> #include <stdarg.h>
>> #include <stdbool.h>
>> #include <stddef.h>
>> #include <stdint.h>
>>
>> with (among other relevant options) -MD, and with a cross compiler.
>> The resulting dependencies are
>>
>> std.o: std.c /usr/local/x86_64-unknown-linux/sys-include/inttypes.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/features.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/sys/cdefs.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/bits/wordsize.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/gnu/stubs.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/gnu/stubs-64.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include/stdint.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include/stdint-gcc.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include-fixed/limits.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include-fixed/syslimits.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/limits.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/bits/posix1_lim.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/bits/local_lim.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/linux/limits.h \
>>  /usr/local/x86_64-unknown-linux/sys-include/bits/posix2_lim.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include/stdarg.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include/stdbool.h \
>>  /build/gcc/5.4.0-x86_64/gcc/include/stddef.h
>>
>> This tells us that this uses not just compiler provided headers,
>> but also ones provided by the platform (inttypes.h, limits.h,
>> plus their descendants). I.e. we would not only become
>> dependent upon whatever the platform library provides, but we'd
>> also become dependent on there being a respective header
>> installed in the first place. While that's quite likely a true
>> assumption for native builds, I don't think we should assume this
>> for cross builds.
>>
>> Additionally, looking through the resulting preprocessed file I also
>> find
>>
>> typedef int __gwchar_t;
>>
>> typedef struct
>>   {
>>     long int quot;
>>     long int rem;
>>   } imaxdiv_t;
>>
>> extern intmax_t imaxabs (intmax_t __n) __attribute__ ((__nothrow__)) 
> __attribute__ ((__const__));
>>
>> extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
>>       __attribute__ ((__nothrow__)) __attribute__ ((__const__));
>>
>> extern intmax_t strtoimax (__const char *__restrict __nptr,
>>       char **__restrict __endptr, int __base) __attribute__ ((__nothrow__));
>>
>> extern uintmax_t strtoumax (__const char *__restrict __nptr,
>>        char ** __restrict __endptr, int __base) __attribute__ 
> ((__nothrow__));
>>
>> extern intmax_t wcstoimax (__const __gwchar_t *__restrict __nptr,
>>       __gwchar_t **__restrict __endptr, int __base)
>>      __attribute__ ((__nothrow__));
>>
>> extern uintmax_t wcstoumax (__const __gwchar_t *__restrict __nptr,
>>        __gwchar_t ** __restrict __endptr, int __base)
>>      __attribute__ ((__nothrow__));
>>
>> typedef struct {
>>   long long __max_align_ll __attribute__((__aligned__(__alignof__(long 
> long))));
>>   long double __max_align_ld __attribute__((__aligned__(__alignof__(long 
> double))));
>> } max_align_t;
>>
>> none of which we want, I think (and I didn't even try to look at the
>> set of resulting #define-s). Yes, the function declarations are benign
>> as using them will result in linking failures, but it's still stuff getting
>> added to the name space which we don't need or want.
> 
> Is this perhaps a side effect of using -std=gnu99?
> 
> Does it change when using -std=c99?

Only the max_align_t one goes away (also when explicitly using
-std=gnu99). And the set of descendants of limits.h shrinks, but not
to an empty list.

Jan

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