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

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> In the 10.5 API almost all int or unsigned int parameters and return
> values are changed to NSInteger and NSUInteger.
> The NSInteger and NSUInteger types are defined to be the same size as
> pointers.
> 
> I'm close to having this change complete and ready to commit for the
> GNUstep-base library, and wouldn't be worried about it but for the fact
> that it breaks compatibility on 64bit processors (though 32bit systems
> should be unaffected), since most 64bit processsors use 32bit integers
> and 64bit pointers, so the change means that most integers passed in the
> API will be twice as big on 64bit systems.
> 
> 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.
> 
> Possibly there will also be issues with archived data (including gorm
> files).
> 
> So, how should we go about this?  Do we update GNUstep-base, accepting
> that parts of the gui and back libraries (and applications and data)
> will be broken by the change, then fix breakage as we find it, or do we
> attempt to do some sort of coordinated change?
> If the latter, what would we try to coordinate, how would we manage it,
> and how would we test it?
> 

I would say that we should go on with this change. At some point we will
have to do it to stay Cocoa compatible, so better do it now. On the
other hand we need to make sure that we catch most of the problems as
early as possible. Could those developers with 64-bit environments (I
still don't use one) compile gui, back (all backends!) and as much
applications as possible and report or fix all the compiler warnings
they get.
At the moment it is possible to compile gui and back with only limited
compiler warnings, so most of the resulting warnings should be caused by
the change.
What we also need to do is change gui to use the new types. That is a
lot more effort, I think it is even bigger than changing base.
As far as Gorm file are concerned I would expect that they will stay the
same. The on disk format must be compatible between 32- and 64-bit, so I
don't expect any changes here. We may have to replace all calls to
encodeInt with encodeInt32 and the same for decode, though.