From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Xen-devel <xen-devel@lists.xen.org>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH 1/6] xen/build: Allow the use of C freestanding headers
Date: Wed, 13 Jul 2016 16:17:38 +0100 [thread overview]
Message-ID: <20160713151738.GB71226@deinos.phlegethon.org> (raw)
In-Reply-To: <f4b8c3c2-afdc-56d3-837a-58fecf041c63@citrix.com>
At 14:46 +0100 on 13 Jul (1468421211), Andrew Cooper 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.
Broken in theory or actually causing a problem right now?
> We cannot expect to use -Wformat and not the compiler provided
> inttypes.h.
Since we're not using the compiler-provided printf(), I think that
we're on pretty thin ice with -Wformat anyway. But as long as our
own PRI* macros match our type definitions, all should be well, right?
> 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.
If a compiler we support does that, we can update our integer type
definitions, like we do for attribute annotations, &c.
BTW, I can absolutely see the argument for deferring to the compiler
in C implementation details. I think that would have to include
removing all the implementation-reserved names from Xen so we don't
clash with compiler headers.
But in practice it seems to be messy enough to be better avoided --
having /usr/include on the search path is pretty silly.
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-13 15:17 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 [this message]
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
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=20160713151738.GB71226@deinos.phlegethon.org \
--to=tim@xen.org \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=sstabellini@kernel.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).