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

[David Ayers]

Am Sonntag, den 22.02.2009, 12:50 +0000 schrieb Richard Frith-Macdonald:


> > 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.

Are you referring to the typedef or also about the strictness of
decoding?  Because currently anything encoded with NSInteger before your
changes will not be decoded to the "new" NSInteger unless the sanity
checks are removed.

> > 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.

Well yes... for any newly created archive... but what's with the
archives that currently already contain NSInteger... the are currently
encoded with 'I' and our decoding will expect 'i' after you commit.

> >> 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.

I understand that you are worried about a different issue.  But please
be aware that changing the NSInteger typedef will also make archives
containing them unloadable.

> >> 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.

This case is special in that it intentionally encodes as "int" and
decodes as NSInteger (and encodes as "unsigned int" and decodes as
"NSUInteger") and vice versa.  [Well if you chose the "correct" #if]

Now it may not be a big issue at all since we hardly @encode(NSInteger).
The only instance I found is NSPointerArray which I believe has never
been released.

> 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.

Indeed we also need to worry about this class of issues. 

> 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).

Well.. this is not arch dependent (well with the exception that on some
archs 'int' may be unsigned but I don't think we support them anyway).
But I get an exception with the test case encoding as int and decoding
as NSInteger, which implies to me that we are pretty strict in what we
expect during decoding.

Cheers,
David