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

Re: use bytes; - what does/should it mean?

Thread Previous | Thread Next
Nick Ing-Simmons
March 12, 2001 07:54
Re: use bytes; - what does/should it mean?
Message ID:
Simon Cozens <> writes:
>On Mon, Mar 12, 2001 at 12:56:50PM +0000, Nick Ing-Simmons wrote:
>> So at the risk of opening the flood-gates - what does p5p think 
>> use bytes should do? 
>At risk of being rude, haven't we done this *enough* times already now?

It seems like it, but if you review the mail you will discover we have not 
discussed what 'use bytes' means for a while.

We have discussed "character semantics" i.e. chr(N)/pack('C')/ord(ch) to 
death for the normal case. And there is a near consensus on what those mean 
(at the perl level) now.

But we have (in my case deliberately) not discussed how they are affected 
by 'use bytes'.

Last time we discussed use bytes we had far less idea how the internals were 
going to work and we had a less well defined perl-level model.

Given that we have now (I hope!) cleared away a lot of the "character 
semantics" confusion, and explained how to do some of the things that 
5.6's 'use bytes' was being used as a kludge for in a clean manner
I expect/hope some people to have changed their position. 

I am essentialy asking for a boolean answer A vs B - but I will entertain
minor variants and clarifications.

>you merely going to keep asking this question over and over until you get the
>answer you want?


I would like a clear Larry ruling but apparently I am not going to get one.
(The apparent Larry ruling can be read in the Camel-III and differs from 
what is implemented, saddly the Camel-III disgrees with itself in places.)

So I am going to ask it once more and see if we get "an answer".

I don't care what the answer is so long as we get one.

Right now some it seems some parts of perl do things one way (expose the guts)
and some do it the other (take steps to make it "safe"). 

I don't see how that can make anyone happy, and it is not acceptable to me.

So if we fail to get an answer which allows a more efficient solution
I intend to collect everything behind one macro (i.e. DO_UTF8 as it is 
already used most (all but 14) places that effect the changed behaviour) and 
provide both options in #if hackable manner. 

The "expose the internals" scheme is particularly fragile on EBCDIC right
now as the SvUTF8_on form is so radically alien to system's expectation.

Nick Ing-Simmons <>
Via, but not speaking for: Texas Instruments Ltd.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About