This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

failure notice


(Sorry if you get this twice, it looks like the first attempt to send it
failed ...)

Paolo Carlini wrote:

>>(gdb) x/32xh i_lit
>>0x7ffff738:     0x6200  0x6c00  0x6100  0x6300  0x6b00  0x2000  0x7000
0x6500
>>0x7ffff748:     0x6100  0x7200  0x6c00  0x2000  0x6a00  0x6100  0x7300
0x6d00
>>0x7ffff758:     0x6900  0x6e00  0x6500  0x2000  0x7400  0x6500  0x6100
0xa000
>>0x7ffff768:     0x0000  0x0000  0x0000  0x0000  0x7fff  0xf738  0x004b
0x3801
>>(gdb) x/32xh i_arr
>>0x4e8c18:       0x0062  0x006c  0x0061  0x0063  0x006b  0x0020  0x0070
0x0065
>>0x4e8c28:       0x0061  0x0072  0x006c  0x0020  0x006a  0x0061  0x0073
0x006d
>>0x4e8c38:       0x0069  0x006e  0x0065  0x0020  0x0074  0x0065  0x0061
0x0000
>>0x4e8c48:       0x0000  0x0000  0x0000  0x0289  0x0000  0x0001  0x0000
0x0001
>>
>>This does look like an endianness problem, but I'm not sure (what is the
<>relationship between UCS-2BE/UCS-2LE and the endianness of the
platform?).
>>S/390 is a big-endian machine.
>>
>For the time being, let us concentrate on the first fail, which seems
>easier to deal with.
>Indeed, I agree with you that this is an endianness problem. And,
>AFAICT, the BE in UCS-2BE is for Big Endian, therefore this is the right
>test to carry on s390.

Thinking about it, isn't the library completely correct?  The bytes
actually returned in i_arr read

  0x00 0x62 0x00 0x6c 0x00 0x61 ...

which does appear to be the correct UCS-2BE representation of the
string in question.

However, the value it is compared against is

  0x62 0x00 0x6c 0x00 0x61 0x00 ...

which is *not* a proper UCS-2BE representation.

This value is generated in the test case source like this:

  int_type        i_lit_base[25] =
  {
    0x6200, 0x6c00, 0x6100, 0x6300, 0x6b00, 0x2000, 0x7000, 0x6500, 0x6100,
    0x7200, 0x6c00, 0x2000, 0x6a00, 0x6100, 0x7300, 0x6d00, 0x6900, 0x6e00,
    0x6500, 0x2000, 0x7400, 0x6500, 0x6100, 0xa000
  };


But it obviously depends on the endianness of the host platform
how these short ints are represented as byte sequence.  The test
case does not appear to take this into account properly.  It looks
like the test case can only be correct on little-endian hosts.

However, I do not quite understand why the test appears to succeed
on other big-endian platforms like alpha and sparc ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]