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

[Eric Wasylishen]

>> 
>> 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?
> 
> Yes, I already fixed this to use a new archive format with variable length 
> array counts.  Looks like the old archive format has had this bug practically 
> forever (fixed, system-dependent size of array counts) ... which is really 
> disappointing given than quite an effort was make to ensure that all the 
> archiving of actual values was safe across systems with different  word sizes 
> etc.
> 
Great, thanks!

Sorry to bug you more, but here's another weird thing: Any idea how this gorm 
archive could have a version of 40000? (0x00009c40)

http://cvs.savannah.gnu.org/viewvc/gap/system-apps/Zipper/Resources/MainMenu.gorm/objects.gorm?root=gap&view=markup

I just tried opening Zipper.app and got an exception because the archive 
version was triggering the new code path.

Also, should we bump the GNUSTEP_BASE_SUBMINOR_VERSION so archives saved with 
gnustep-base trunk between the last release and now will continue to work?

Eric