On Wed, 5 Oct 2005 08:12:11 -0700 (PDT), rajarshi das
<[EMAIL PROTECTED]> wrote
> Hi,
> I made the following change to utf8.c on EBCDIC:
>
> > *** /u/isldev2/perl-5.8.6/utf8.c Fri Sep 30 02:26:42
> > 2005
> > --- utf8.c.modified Tue Oct 4 03:37:46 2005
> > ***************
> > *** 193,198 ****
> > --- 193,201 ----
> > if (!UTF8_IS_START(u))
> > return 0;
> > + #ifdef EBCDIC
> > + u = NATIVE_TO_UTF(u);
> > + #endif
> > len = UTF8SKIP(s);
> >
> > This change, along with certain modifications to the
> > test case t/uni/class.t, have fixed all the failures
> > in t/uni/class.t on perl-5.8.6.
However I think the success of some tests in t/uni/class.t
is a pretense since t/uni/class.t seems to have a bug on EBCDIC.
(and maybe another uncertain regex bug hiding ...)
For example the first test in t/uni/class.t is not portable to EBCDIC:
my $str = join "", map chr($_), 0x20 .. 0x6F;
# make sure it finds built-in class
is(($str =~ /(\p{Letter}+)/)[0], 'ABCDEFGHIJKLMNOPQRSTUVWXYZ');
In EBCDIC, the code value for 'A' is 0xC1, instead of 0x41 in ASCII.
Thus $str here doesn't contain 'A' on EBCDIC platform.
This test may be cut down as below.
is(("\x4E" =~ /(\p{Letter}+)/)[0], 'N');
If this test results in "true", the result means that
"+" =~ /(\p{Letter}+)/ # cf. "\x4E" eq "+" in EBCDIC
is incorrectly true on EBCDIC platform, doesn't it?
Regards,
SADAHIRO Tomoyuki
