Re: Test results from base Linux/PPC
Richard Frith-Macdonald wrote: On 4 Apr 2011, at 15:56, Wolfgang Lux wrote: --- Running tests in base/NSNumber --- base/NSNumber/test00.m: Failed test: test00.m:111 ... NSDecimalNumber charValue works The latter of these fails due to a mismatch between signed and unsigned char. The test uses (char)200 == [val1 charValue] The result of charValue is signed char, but char is unsigned by default on powerpc. Thanks ... I just changed the test to be '(signed char)200 == [val1 charValue]' since, for consistency, charValue always returns a signed char. 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. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test results from base Linux/PPC
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test results from base Linux/PPC
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Test results from base Linux/PPC
Running the tests on a freshly installed Ubuntu Lucid Lynx, I got 5671 Passed tests 14 Dashed hopes 3 Failed tests The three failed tests are --- Running tests in base/coding --- base/coding/decoding.m: Failed test: decoding.m:197 ... decoding version 0 of class NSData Failed test: decoding.m:197 ... decoding version 0 of class NSMutableData --- Running tests in base/NSNumber --- base/NSNumber/test00.m: Failed test: test00.m:111 ... NSDecimalNumber charValue works The latter of these fails due to a mismatch between signed and unsigned char. The test uses (char)200 == [val1 charValue] The result of charValue is signed char, but char is unsigned by default on powerpc. For the former I don't know the cause (and can't debug ATM, since gdb simply crashes on this system). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test results from base Linux/PPC
On 4 Apr 2011, at 15:56, Wolfgang Lux wrote: --- Running tests in base/NSNumber --- base/NSNumber/test00.m: Failed test: test00.m:111 ... NSDecimalNumber charValue works The latter of these fails due to a mismatch between signed and unsigned char. The test uses (char)200 == [val1 charValue] The result of charValue is signed char, but char is unsigned by default on powerpc. Thanks ... I just changed the test to be '(signed char)200 == [val1 charValue]' since, for consistency, charValue always returns a signed char. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
