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.
Here is the tail end of a run of
cd t
./perl -I../lib lib/encode.t.orig
ok 2705
ok 2706
not ok 2707
# Test 2707 got: <UNDEF> (lib/encode.t.orig at line 117)
# Expected: '�' (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: '�' (utf8 decode by name broken for 65)
ok 2710
ok 2711
ok 2712
ok 2713
ok 2714
ok 2715
ok 2716
ok 2717
ok 2718
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 Thu May 10 15:18:17 2001
+++ lib/encode.t Thu May 10 15:23:52 2001
@@ -110,7 +110,9 @@
}
# Spot check a few points in/out of utf8
-for my $i (0x41,128,256,0x20AC)
+my @hex_points = (0x41,128,256,0x20AC);
+ @hex_points = (0xc1,128,256,0x20AC) if (ord('A') == 193);
+for my $i (@hex_points)
{
my $c = chr($i);
my $o = 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?
Thanks for any insight you can provide.
Peter Prymmer
