develooper Front page | perl.perl5.porters | Postings from February 2001

Re: Perl-Unicode fundamentals (was Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2))

From:
Simon Cozens
Date:
February 21, 2001 02:11
Subject:
Re: Perl-Unicode fundamentals (was Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2))
Message ID:
20010221101050.A10851@pembro26.pmb.ox.ac.uk
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> 



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About