Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m

[Richard Frith-Macdonald]

On 27 Feb 2012, at 08:09, Fred Kiefer wrote:

> On 27.02.2012 03:12, Eric Wasylishen wrote:
>> Author: ericwa
>> Date: Mon Feb 27 03:12:19 2012
>> New Revision: 34822
>> 
>> URL: http://svn.gna.org/viewcvs/gnustep?rev=34822&view=rev
>> Log:
>> * Source/NSData.m: Various 64-bit compatibility fixes, mostly changing
>> unsgined to NSUInteger.
>> 
>> Modified:
>>     libs/base/trunk/ChangeLog
>>     libs/base/trunk/Source/NSData.m
> 
> If I checked correctly this patch changed the on disk representation of 
> NSData for archiving on 64bit systems. You changed the encoding of length 
> from unsigned int to NSUInteger and if the underlying archiver doesn't take 
> care of this (Richard, is this the case? Then this mail is pointless), this 
> will result in a different representation. Normally we have to increase the 
> version number for the class to handle such a change and provide different 
> decoding paths for the different versions.

NSArchiver/NSUnarchiver stuff in GNUstep should tolerate different sizes of 
integers (a feature introduced many years ago to handle systems with different 
encodings for different word sizes), so encoding an NSUInteger instead of an 
unsigned should be OK.
But, this introduced an inconsistency in that it would encode NSData with an 
'unsigned' value (via the special methods in the coder/decoder for handling 
NSData), but now encoding must bale data allowing larger data objects (on 64bit 
systems).  I therefore modified NSArchiver/NSUnarchive for consistency ... 
though I haven't actually tried archiving/unarching data objects that large.