[PATCH] Fix type inconsistencies in stdint.h

[Christopher Faylor]

On Sat, Apr 04, 2009 at 08:23:49AM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>
>  Ah, I could address a bit more to these two questions as well:
>
>> Isn't a long 32 bits?  What would be the ABI breakage in changing that
>> one typedef rather than lots of #defines?  
>
>  Yes, a long is 32 bits, but while that makes for binary ABI
>(calling-convention) compatibility it isn't the same thing in the C and C++
>types system.  Therefore the underlying types are an inextricably woven part
>of the overall C-language ABI as well as their physical bit sizes.  Changing
>them certainly has the potential to change the ABI, particularly in C++, but I
>think it also might potentially render some of the compiler's aliasing
>assumptions invalid when linking code using the new definitions against
>objects or libraries using the old.
>
>Changing the limits #defines, OTOH, is absolutely guaranteed ABI
>neutral.  They really are "just constants" at runtime, and constants
>don't get mangled or alias anything.  So I reckon it's a safer way to
>proceed and I don't yet see any potential 64-bit problems down the line
>if we leave everything as it currently stands.
>
>Can you see anything I've overlooked in this analysis?

I don't entirely understand when people think it's ok to make sweeping
changes for 1.7 and when they think we need to be conservative.

I think it is very regrettable that Cygwin doesn't have the same int
types as linux and it would be interesting to see how much would be
broken by changing these types.

cgf