On Wed, Feb 21, 2001 at 10:01:41AM +0000, Nick Ing-Simmons wrote: > chr(0)..chr(255) - 'byte-able' has EBCDIC "cultural info" when SvUTF8_off > (isalpha, tolower etc.) > - to upgrade do e2a[ch] and SvUTF8_on > e2a array is equivalent to > ext/Encode/Encode/cp1047.ucm > - e.g. chr(0xC1) can be C 0xC1,SvUTF8_off > or 0x41,SvUTF8_on > chr(256)... - only as UTF8 - uses Unicode code points. Strongly agree. > I am also assuming that pack('U',...) implies Unicode code points, > while pack('C',...) has legacy EBCDIC nature (to match ord/chr). Agree. > perhaps we change our minds and make that what I thought it was i.e. > v5.6.0 eq pack('U',5,6,0) Yes, that would work. I'm just concerned about the difference between the "numeric" meaning of vstrings and the "string" meaning. I don't want vstrings to come back through the e2a grinder and have "use 5.6.0" try to ensure we're running Perl version 35.36.0 or whatever it is on EBCDCIC. > we may need an sv_downgrade_latin1() which does NOT run result through a2e[] > and extend "transparency" to socket() by calling that there. Right, yes. This is what I mean by distinguishing between numeric and string uses. -- Apr 13 11:05:20 apollo13 fsck[3927]: root, we have a problem. - Jeff Gostin <jgostin@shell2.ba.best.com>