Re: Test results from base Linux/PPC

[Wolfgang Lux]

I wrote:

> 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.

Now I see the problem: The failing test data is read from a file that  
apparently was created on a little endian machine. So I assume that  
the conversion of a (static) string into an NSData object using  
NSUnicode encoding (aka UTF-16) is lacking a byte swap?

Wolfgang