r220177 - [modules] Add support for #include_next.

JF Bastien jfb at chromium.org
Tue Oct 21 07:14:46 PDT 2014

On Oct 21, 2014 6:11 AM, "Aaron Ballman" <aaron at aaronballman.com> wrote:
> On Mon, Oct 20, 2014 at 7:21 PM, Richard Smith <richard at metafoo.co.uk>
> > On Mon, Oct 20, 2014 at 4:16 PM, Aaron Ballman <aaron at aaronballman.com>
> > wrote:
> >>
> >> Like I said, it's a weak preference. ;-) However, "it makes it easier
> >> to do nonstandard things" isn't really a ringing endorsement for
> >> making this change be consistent with GCC in my book. At the end of
> >> the day, there's int8_t and uint8_t definitions, which do the standard
> >> thing, and don't require messes (that I'm aware of).
> >
> >
> > That's circular; our own stdint.h uses __UINT_* to define those types.
> My point is that it doesn't have to -- those can be defined entirely
> using standard fundamental types. However, I would agree that using
> the fundamental types could make this file considerably more messy,
> and this is information the compiler already has on hand.

The fundamental sized types *come from this file*.

Either stdlibs guess the fundamental types using configure, or they ask the
compiler (or the compiler plays games with include_next, where it may do
the same trick of asking itself). These macros allow one to ask the
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141021/dd7c390e/attachment.html>

More information about the cfe-commits mailing list