Thanks. This test now passes on PowerPC linux. As for the other two
failures, it looks like an endianness issue. Adding two log statements
NSLog(@" decoded object = %@", [decodedInstance objectAtIndex: 0]);
to decoding.m the interesting part of the output becomes:
Passed test: decoding.m:171 ... decoding current version of
class NSData
2011-04-05 13:25:10.517 decoding[10747] decoded object = <feff0057
00650020 006e0065 00650064 00200063 006f006e 00730074 0061006e
00740020 00640061 00740061>
Failed test: decoding.m:198 ... decoding version 0 of class NSData
2011-04-05 13:25:10.523 decoding[10747] decoded object = <fffe5700
65002000 6e006500 65006400 20006300 6f006e00 73007400 61006e00
74002000 64006100 74006100>
Passed test: decoding.m:171 ... decoding current version of
class NSMutableData
2011-04-05 13:25:10.525 decoding[10747] decoded object = <feff0057
00650020 006e0065 00650064 00200063 006f006e 00730074 0061006e
00740020 00640061 00740061>
Failed test: decoding.m:198 ... decoding version 0 of class
NSMutableData
2011-04-05 13:25:10.531 decoding[10747] decoded object = <fffe5700
65002000 6e006500 65006400 20006300 6f006e00 73007400 61006e00
74002000 64006100 74006100>
As you can see, byte order in the NSData objects is swapped in the
failed tests, which is sort of strange -- after all no byte swapping
should occur on a big-endian architecture as far as I recall.