Re: Compatibility breakage involved in upgrading to the MacOS-X 10.5 API

[David Chisnall]

On 22 Feb 2009, at 09:55, Richard Frith-Macdonald wrote:

> Obviously that breaks binary compatibility on 64bit systesm, but  
> perhaps less obviously it also breaks source code compatibility in  
> quite a few places (wherever the API changes from passing a pointer  
> to a 32bit integer to now be passing a pointer to a 64bit integer),  
> and will cause compiler warnings wherever we assign a 64bit integer  
> to a 32bit one.

Can we defer this problem by defaulting to #defining NSInteger as  
intptr_t and NSUInteger as uintptr_t, but provide a GS_LEGACY_64 mode  
that compiles them as int and unsigned int and emits a warning?  That  
way new code can use NSInteger and NSUInteger on 64-bit platforms in  
either mode, as long as all packages are compiled with the same  
options.  Then, once all existing code has been modified to use the  
new types turn the flag off and break the ABI once?

I suspect the bigger problem will be the CGFloat type, which is now  
used all over Cocoa.  I really don't understand the reason for this  
change.  It's float on 32-bit and 64-bit on 64-bit platforms, which  
almost sounds sensible until you remember that 32-bit and 64-bit  
floats are both computed using the 80-bit x87 unit on 32-bit x86 and  
so are the same speed, but are computed with the SSE unit on x86-64  
and so calculations on doubles are often slower than the equivalent  
calculations on floats.  If anything, the opposite definitions would  
make more sense for the architectures that Apple supports (especially  
since most GPUs still can't handle doubles sensibly, and a lot of the  
geometry calculations that use these types will probably end up being  
offloaded to the GPU in future versions).

David