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

[Richard Frith-Macdonald]

On 22 Feb 2009, at 12:09, David Ayers wrote:

> Am Sonntag, den 22.02.2009, 09:55 +0000 schrieb Richard Frith- 
> Macdonald:
>
> > 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.
>
> And those warnings should be taken seriously in any heterogeneous
> environment and the source code adapted accordingly.

Yes... though in practice most will be harmless (but you have to check  
anyway).

> > Possibly there will also be issues with archived data (including gorm
> > files).
>
> IIRC, the actual size of the archived data is encoded into the archive
> and so if we heeded that information when decoding rather than the
> expected target size, we should be fine decoding the old values.

Yes, but I'm not sure that this is true absolutely everywhere ... we  
need to check.

> But it seems that we are currently very strict in what we expect.  And
> we have a bug... NSInteger is typedef'ed to gsaddr (which is typed def
> to gsuaddr) instead of gssaddr!

Not in my (as yet uncommitted) code.

> So we are actually currently encoding unsigned integers when encoding
> NSInteger.

Not really an issue ... since my changes to move everything over to  
NSInteger and NSUInteger haven't been committed yet, and when they are  
the commit will also include my fix to the typedef along with various  
other related fixes.

> > 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?
>
> I think we need to fix the NSInteger define.  I think we should  
> believe
> the archive/stream which were are decoding and convert into the  
> expected
> type.  We could warn if they types don't match but I don't think we
> should abort unless the types are so incompatible that we cannot
> sensibly convert.

Really archiving/encoding/decoding should not be an issue ... except  
for errors in conversion where perhaps we encode an NSInteger and  
decode with a pointer to the wrong type:
eg.
int val;
[coder decodeValueOfObjCType: @encode(NSInteger) at: &val];
Which could decode an 8 byte value into a variable which is only 4  
bytes long.

That sort of coding error is easy to make when converting a lot of  
code from using one type to another ... eg 'val' is actually an ivar  
declared in a separate header file, and you think you changed it from  
int to NSInteger, but forgot.

We really need to check the code for any places where we pass pointers.

> > If the latter, what would we try to coordinate, how would we manage
> > it, and how would we test it?
>
> I've attached a small test case that should test NSInteger... But I
> think for the test we want, we should create/commit architecture
> specific files in the test suite which should always decode to  
> expected
> values on any platform.

Thanks .. I think we already have such tests for basic types.  What we  
don't have is an exhaustive set of coding tests for every coding  
capable class.
It would be good to add more.

There are a few odd cases in the API where pointers are used.  For  
instance, you can get the indexes from an NSIndexSet into a buffer.
Now, if your code makes the buffer big enough for 10 unsigned int  
indexes (40 bytes) and retrieves them, but the base library is changed  
to use NSUInteger and copies 10 indexes (80 bytes) into the buffer,  
you have a problem.
Those are the sort of issues I'm most concerned about, as I *hope*  
that our archiving/coding is architecture independent anyway  
(NSArchiver and NSUnarchiver and all coding using them certainly was  
architecture independent at one point).