gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test results from base Linux/PPC


From: Richard Frith-Macdonald
Subject: Re: Test results from base Linux/PPC
Date: Tue, 5 Apr 2011 14:10:12 +0100

On 5 Apr 2011, at 13:22, Wolfgang Lux wrote:

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

Yes ... I'd missed that the original data came from the string and, as it's 16 
bit characters, has byte order structure.
I've modified the test to swap the bytes if the test is run on a big endian 
system.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]