On 2012-02-27, at 3:35 AM, Richard Frith-Macdonald wrote: > > 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.
Hm, I seem to be getting lots of test failures now (on 64-bit linux). Testing basictypes.m... Running base/coding/basictypes.m... ./obj/basictypes: Uncaught exception NSInternalInconsistencyException, reason: expected array count 27 and got 116002156320 /usr/local/bin/gnustep-tests: line 300: 22653 Aborted $RUN_CMD Failed file: basictypes.m aborted without running all tests! Testing decoding.m... Running base/coding/decoding.m... Passed test: decoding.m:198 ... decoding current version of class NSArray Failed test: decoding.m:230 ... decoding class NSArray: <NSException: 0x82bc38> NAME:NSInternalInconsistencyException REASON:expected array count 2 and got 9395417345 INFO:(null) … etc … I think the problem is, in -[NSUnarchiver decodeArrayOfObjCType:count:at:], it calls -[NSData deserializeDataAt:ofObjCType:atCursor:context:] which doesn't do the automatic handling of 32-bit vs 64-bit. So if NSUInteger is 64-bits, decodeArrayOfObjCType:count:at: will attempt to read a 64-bit array length value even if the archive only has a 32-bit length value stored there. Not sure what the solution is… seems to me like you would need a new archive format where array lengths are always stored as 64-bits. But my changes in NSData should be safe without the NSArchiver/NSUnarchiver changes, I think? Cheers, Eric _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev