p5pRT
commented
23 years ago From pvhp@forte.com
perl -Ilib -MDevel::Peek -e 'print Dump("\x{FF}")'
$ ./perl -Ilib -MDevel::Peek -e 'print Dump("\x{FF}")' SV = PV(0x1a83f9c4) at 0x1a828e48 REFCNT = 1 FLAGS = (POK\,READONLY\,pPOK\,UTF8) PV = 0x1a82efc8 "C\277"\0 CUR = 2 LEN = 3 $
How about
./perl -Ilib -MDevel::Peek -e 'print Dump("\x{FF}" & "2")'
$ ./perl -Ilib -MDevel::Peek -e 'print Dump("\x{FF}" & "2")' SV = PV(0x1a829090) at 0x1a828e78 REFCNT = 1 FLAGS = (POK\,READONLY\,pPOK\,UTF8) PV = 0x1a82f038 "C\262"\0 CUR = 2 LEN = 3
and
./perl -le 'print ord("2")'
$ ./perl -le 'print ord("2")' 242 $
op/chop..............FAILED at test 31
perl -Ilib -MDevel::Peek -e 'print Dump("bc\x{1234}")'
$ ./perl -Ilib -MDevel::Peek -e 'print Dump("bc\x{1234}")' SV = PV(0x1a83f9cc) at 0x1a828e48 REFCNT = 1 FLAGS = (POK\,READONLY\,pPOK\,UTF8) PV = 0x1a82efc8 "Bb\0c\341h\264"\0
This is certainly interesting\, how the "bc" has become mangled. but I think I know what is happening. When the \x{1234} is met\, the so-far-accumulated string is UTF-8-ized. Now\, the code foolishly thinks & 0x80 signifies a high-bit byte that requires UTF-8-fication. Not so for EBCDIC\, where 'b' and 'c' are & 0x80. The stink is coming from toke.c.
Note too the "B" characters inserted into the C\<print "ok\n";> statements that are a part of the comp/require.t test. See my original report for things like:
String found where operator expected at bleah.pm line 1\, near "BpBrBiBnBt "BoBk" (Do you need to predeclare BpBrBiBnBt?)
[answer: no I do not need to predeclare BpBrBiBnBt I need for perl to not
try to improperly utf8-ize C\
$ echo B | od -t d1 0000000000 194 21 0000000002
Peter Prymmer
Migrated from rt.perl.org#5094 (status was 'resolved')
Searchable as RT5094$