From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
WeiLiu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Tim Deegan <tim@xen.org>, IanJackson <ian.jackson@eu.citrix.com>,
Xen-devel <xen-devel@lists.xen.org>,
Julien Grall <julien.grall@arm.com>
Subject: Re: [PATCH 0/6] xen/build: Use system headers
Date: Wed, 22 Jun 2016 06:50:02 -0600 [thread overview]
Message-ID: <576AA59A02000078000F7AA6@prv-mh.provo.novell.com> (raw)
In-Reply-To: <844d6001-c2e6-fae1-8b8c-2114528f1e8a@citrix.com>
>>> On 22.06.16 at 14:33, <andrew.cooper3@citrix.com> wrote:
> On 22/06/16 13:26, Jan Beulich wrote:
>>>>> On 22.06.16 at 13:24, <andrew.cooper3@citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-06-22 12:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-22 11:24 [PATCH 0/6] xen/build: Use system headers Andrew Cooper
2016-06-22 11:24 ` [PATCH 1/6] xen/build: Allow the use of C freestanding headers Andrew Cooper
2016-06-22 11:46 ` George Dunlap
2016-06-22 13:12 ` Tim Deegan
2016-07-13 13:46 ` Andrew Cooper
2016-07-13 15:17 ` Tim Deegan
2016-08-01 9:50 ` Jan Beulich
2016-08-01 9:52 ` Jan Beulich
2016-06-22 11:24 ` [PATCH 2/6] xen/build: Use the system stdarg.h header Andrew Cooper
2016-06-22 12:31 ` Jan Beulich
2016-06-22 11:24 ` [PATCH 3/6] xen/build: Use the system stdint.h header Andrew Cooper
2016-06-22 11:24 ` [PATCH 4/6] xen/build: Use the system limits.h header Andrew Cooper
2016-06-22 11:24 ` [PATCH 5/6] xen/build: Use the system stddef.h and inttypes.h headers Andrew Cooper
2016-06-22 11:24 ` [PATCH 6/6] xen/build: Use the system stdbool.h header Andrew Cooper
2016-06-22 12:43 ` Jan Beulich
2016-06-22 13:02 ` Andrew Cooper
2016-06-22 12:26 ` [PATCH 0/6] xen/build: Use system headers Jan Beulich
2016-06-22 12:33 ` Andrew Cooper
2016-06-22 12:50 ` Jan Beulich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576AA59A02000078000F7AA6@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).