r220177 - [modules] Add support for #include_next.

[Aaron Ballman]

On Tue, Oct 21, 2014 at 10:14 AM, JF Bastien <jfb at chromium.org> wrote:
>
> 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>
>> wrote:
>> > 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 compiler.

The compiler has documented sizes for fundamental types which can be
used to define the types in this file. Eg)

typedef signed char        int8_t;
typedef short              int16_t;
typedef int                int32_t;

Nothing says we cannot provide this in similar fashion for our
stdint.h; though, as I pointed out, that could make this file *very*
ugly with a bunch of target-specific #ifs everywhere to ensure the
proper definitions of *int*_t and friends. I can understand not
wanting to do that (especially since the compiler already has this
information internally).

~Aaron