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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

~Andrew

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