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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
