On Tue, Oct 21, 2014 at 10:14 AM, JF Bastien <[email protected]> wrote: > > On Oct 21, 2014 6:11 AM, "Aaron Ballman" <[email protected]> wrote: >> >> On Mon, Oct 20, 2014 at 7:21 PM, Richard Smith <[email protected]> >> wrote: >> > On Mon, Oct 20, 2014 at 4:16 PM, Aaron Ballman <[email protected]> >> > 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
