On Tue, Feb 08, 2005 at 08:52:28PM +0000, Ton Hospel wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Ton Hospel) writes: > > Am I always supposed to clean up that kind of unwanted state if I > > get an sv from a TARG ? > > Shouldn't perl itself take care of that before presenting a TARG ? > > If not so, what's the way you're supposed to get a "clean slate" before > > starting to use the value ? > > > > Is maybe perl riddled with variations of this bug ? > > Mm, this same problem is easy to trigger in other operators. > Just opening pp.c and scanning for dTARGET for an operator > that may set utf8 on it, leads as first candidate to chop. > > And indeed, it's an immediate hit: > > perl -wle 'use Devel::Peek; my $a=$b="\xff"; utf8::upgrade($a); Dump(chop) > for $a,$b'
... > Malformed UTF-8 character (byte 0xff) in subroutine entry at -e line 1. > The second time around the \xff incorrectly gets the utf8 flag > > Things like lc() do SvUTF8_off beforehand, but there are other forms > of state beyond utf8, for example tie magic. And the TARG result itself > can be gotten to using "for" to make an alias: > Many (most ?) perl operators can be triggered with some form of > this problem, e.g. here is addition: Interesting. Worrisome. I presume the intent of TARGET is to save overhead of allocating scalars. As the problem seems to be endemic, is the solution to create a new function (er, or macro) that clears all state, and use that in place of things like the piecemeal utf8 flag clearing. Nicholas Clark
