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. > >> >> When this discussion comes up about supporting nonstandard things from >> MSVC, the usual watermark is: are there system headers we can't >> compile without this change? > > > Well, we ship such a system header with Clang, so yes. But we can also > change that header if we think that's a better alternative. As I said, this is a weak preference of mine (and a few folks seem to have a strong preference for unconditionally providing those macros), so I'm fine with going the direction the majority wishes for. I do not see any incompatibility worries we may run into with MSVC today -- they currently define everything in terms of fundamental types. Do we have to worry about a future MSVC version providing their own macros with equivalent functionality, but different names? ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
