'o' modifier clarification needed

[nysus]

The perlre states: "(the 'o' modifier) avoids expensive run-time recompilations, and is useful when the value you are interpolating won't change over the life of the script. However, mentioning /o constitutes a promise that you won't change the variables in the pattern. If you change them, Perl won't even notice."

So I wrote this:

--------------------------
my $pattern = "homey";
my $value = "homeylovekins";
match();
$pattern = "wigwam";
match();

sub match {
    if ($value =~ /$pattern/o) {
        print "yes";
    } else { print "no"; }
}
-------------------------------------

But still got this: yesno

What am I missing? Shouldn't the pattern match string remain "homey" for the duration of the script per the perldoc? Thanks, Monks.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop";
$nysus = $PM . $MCF;
Click here if you love Perl Monks

[tye]

Looks like a bug. Perl 5.004 (HP/UX) gives the expected "yesyes" but Perl 5.6 (Win32) says "yesno" for me. I wish I had more versions of Perl handy for testing (well, dropping "my"s and adding "&"s makes perl4 say "yesyes", but I didn't expect that to be of interest to many)...

        - tye (but my friends call me "Tye")

[nysus]

Yup, a bug: Check out this bug report at ActiveState's site.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop";
$nysus = $PM . $MCF;
Click here if you love Perl Monks

[blakem]

Perl 5.005_03 and 5.6.0 for i386-linux both print "yesyes"

-Blake

[nysus]

That might explain it, then. I have Perl 5.6 (Win 32), ActiveState. A bug, eh?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop";
$nysus = $PM . $MCF;
Click here if you love Perl Monks

[crazyinsomniac]

I get the same *bug* on both ActivePerl and IndigoPerl.

What appears to be going is that perlfunc:reset is being called, when the o switch is supposed to prevent that from happening. It's probably a very stupid logic oversight by one of the Win32 porters, as I honestly doubt that there are two sets of idiots knuckleheads to blunder this ;-)

ActivePerl (Win32)
Build 618, Build 623, Build 628

IndigoPerl
Compiled at Aug 27 2000 21:41:04, Compiled at Feb 24 2001 17:05:45, and IndigoPerl Build 626 Compiled at May 6 2001 21:37:25 (they just started numbering their builds).

update: jcwrens freebsd perl 5.005_03 built for i386-freebsd Compiled at Apr 21 2001 08:25:58 is unaffected ;-)

update:: D'Oh! It was thinking of ?? (as in ?PATTERN?). You know, a nice /tell would've been nice ;-)

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

[Dominus]

Says crazyinsomniac:

What appears to be going is that perlfunc:reset is being called, when the o switch is supposed to prevent that from happening.

reset has absolutely nothing to do with /o.

--
Mark Dominus
Perl Paraphernalia

[MeowChow]

This bug affects the qr op as well under Win32.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

[jeroenes]

Hmm... running this with perl 5.6.0 for i386-linux gives me a "yesyes". When compared to the "yesno" that tye reported we apperantly have a os-dependend bug on our hands. Time for japhy to make another patch?

Jeroen
"We are not alone"(FZ)

[Anonymous Monk]

I guess you are running perl 5.6.x on win32 which has psuedo forking enabled. Because the //o changes the optree and that is bad under threads it is disabled. It is fixed in perl 5.7.2 to bee 5.8

sky

[demerphq]

20:29: beretboy: s/ttt/tt/g;
20:34: alienhuman: /o would make that more efficient :)

Cool. Well this bug was unknown to me when a discussion of the /o modifier came up. (Still around in 5.6.1 AS630) I whipped together a little example and discovered unknowing exactly the same bug (crazyinsomniac mentioned this thread but I didn't read it until afterwards, honest :)

At first glance though it seemed to be even wierder.

$\="\n";
$_='aaa';
my $c='a';
print "$c:$_";
print "------";
print "$c:$_" while s/$c/$c++/oe; 
print "------";
print "$c:$_";

Now by all rights this should produce the following sequence:

a:aaa
------
a:aaa
b:baa
c:bca
d:bcd
------
e:bcd

But instead produces:

a:aaa
------
b:aaa
------
b:aaa

So now if we change the statement so its ++$c we get

a:aaa
------
b:baa
c:caa
d:daa
e:eaa
f:faa
.....

Which is unlike what might be expected (even considering the /o bug) until you think about it for a second. With preincremnt The first match succeded ('aaa'=~/a/) and was replaced by itself, then $c was incremented. The second match fails ('aaa'=~/b/) and the loop stops.

So with post increment we get a match ('aaa'=~/a/) but now the replacement happens with the incremented value, so the second match ends up being ('baa'=~/b/) which is then replaced by 'c'.

I suppose this all is obvious, but I thought it was a weird enough example to add to your bug report.

Oh and you can blame:

21:45: alienhuman: /o would make that more efficient :)

:-)

Yves / DeMerphq
--
Have you registered your Name Space?