This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix type inconsistencies in stdint.h


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.


Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]