gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Ayers
Subject: Re: Compatibility breakage involved in upgrading to the MacOS-X 10.5 API
Date: Sun, 22 Feb 2009 13:09:42 +0100

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.

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

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!

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

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

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

Cheers,
David

Attachment: ArchivingUInteger.tar.gz
Description: application/compressed-tar


reply via email to

[Prev in Thread] Current Thread [Next in Thread]