Peter Prymmer <[EMAIL PROTECTED]> writes:
>Nick,
>
>I noted two failures of unit tests in t/lib/encode.t with the perl@10022
>kit on OS/390 recently.  Unfortunately I interpret them to imply that a
>char -> utf(8|ebcdic) -> char round trip is broken on this ebcdic
>platform.

Oh dear, I am sure they used to pass - unless they are new tests.

>not ok 2707
># Test 2707 got: <UNDEF> (lib/encode.t.orig at line 117)
>#      Expected: '=A0' (decode_utf8 not inverse of encode_utf8 for 65)
>ok 2708
>not ok 2709
># Test 2709 got: <UNDEF> (lib/encode.t.orig at line 119)
>#      Expected: '=A0' (utf8 decode by name broken for 65)

The UNDEF is worrying, that says something could not represent 
the code point. Also what is that '=A0' when de-mimed ?

>
>I note that if I switch the 65 to 193 I can get all 2718 tests to
>pass.  That is if I do this:
>
>--- lib/encode.t.orig=09Thu May 10 15:18:17 2001
>+++ lib/encode.t=09Thu May 10 15:23:52 2001
>@@ -110,7 +110,9 @@
>  }
>=20
> # Spot check a few points in/out of utf8
>-for my $i (0x41,128,256,0x20AC)
>+my @hex_points =3D (0x41,128,256,0x20AC);
>+   @hex_points =3D (0xc1,128,256,0x20AC) if (ord('A') =3D=3D 193);
>+for my $i (@hex_points)
>  {
>   my $c =3D chr($i);
>   my $o =3D encode_utf8($c);
>End of Butchery.
>
>then even 2707 and 2709 pass ok.  Should it not be the case that even for
>the char at codepoint 0x41 make it to utf-ebcdic and back alive?

Yes it should. What does EBCDIC 0x41 map to 

>Thanks for any insight you can provide.
>
>Peter Prymmer
-- 
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/

Reply via email to