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