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