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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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