[PATCH] Fix type inconsistencies in stdint.h

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Apr 7 09:03:00 GMT 2009

On Apr  4 11:47, Corinna Vinschen wrote:
> On Apr  4 08:23, 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?
> Sounds right to me.  Given thr LLP64-ness of Win64, it should be no
> problem to stick to the types.

OTOH, we already had to change int32_t and uint32_t from long to int to
avoid warnings.  Given that we already changed that anyway, I'm wondering
if it isn't more sane to align the least and fast types as well.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list