nysus has asked for the wisdom of the Perl Monks concerning the following question:

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"; }
}
-------------------------------------

[download]
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

Replies are listed 'Best First'.
(tye)Re: 'o' modifier clarification needed
by tye (Sage) on Jul 14, 2001 at 10:12 UTC

    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")
[reply]
[reply]
      Perl 5.005_03 and 5.6.0 for i386-linux both print "yesyes"

      -Blake

[reply]
      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

[reply]
(crazyinsomniac) Re: 'o' modifier clarification needed
by crazyinsomniac (Prior) on Jul 14, 2001 at 17:16 UTC
    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;"

[reply]
      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

[reply]
Re: 'o' modifier clarification needed
by MeowChow (Vicar) on Jul 14, 2001 at 19:19 UTC
    This bug affects the qr op as well under Win32. 
       MeowChow                                   
               s aamecha.s a..a\u$&owag.print
[reply]
Re: 'o' modifier clarification needed
by jeroenes (Priest) on Jul 14, 2001 at 10:18 UTC
    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)

[reply]
Re: 'o' modifier clarification needed
by Anonymous Monk on Jul 16, 2001 at 15:53 UTC

    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

[reply]
Re: 'o' modifier clarification needed
by demerphq (Chancellor) on Nov 20, 2001 at 02:53 UTC 
    20:29: beretboy: s/ttt/tt/g;
20:34: alienhuman: /o would make that more efficient :)

    [download]
    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:$_";

    [download]
    Now by all rights this should produce the following sequence: 
    a:aaa
------
a:aaa
b:baa
c:bca
d:bcd
------
e:bcd

    [download]
    But instead produces: 
    a:aaa
------
b:aaa
------
b:aaa

    [download]
    So now if we change the statement so its ++$c we get 
    a:aaa
------
b:baa
c:caa
d:daa
e:eaa
f:faa
.....

    [download]
    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 :)

    [download]
    :-)

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

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom