in reply to Re^18: Reusing a complex regexp in multiple spots, escaping the regexp
in thread Reusing a complex regexp in multiple spots, escaping the regexp

The "code injection" was just a quick and dirty demonstration of a side-effect. Its shows that on a threaded build, the expression which defines the pattern is assembled each time, but then thrown away unused apart from the first iteration. Think for example of a tied array. The following: 
for my $i (0,1) {
    /abc$tied_array[$i]/;
}

[download]
will, on threaded builds, invoke both $tied_array->FETCH(0) and $tied_array->FETCH(1), but will discard the second value.

Dave.

  • Comment on Re^19: Reusing a complex regexp in multiple spots, escaping the regexp
  • Download Code

Replies are listed 'Best First'.
Re^20: Reusing a complex regexp in multiple spots, escaping the regexp
by LanX (Saint) on Apr 17, 2026 at 17:07 UTC
    Thanks for the better example!

    Does this double execution also effect officially embedded (?{CODE}) ?

    Shouldn't this be just documented with /o or (in a better world) even better emitting a warning?

    I'm using side effects in regexes mainly for debugging.

    On a tangent: My system Perl seems to be with thread support, I dunno how often Perl is even installed or used without thread support.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

[reply]
[d/l]
      On unthreaded builds, after the pattern has been assembled and compiled once, the op tree is modified so that on subsequent executions, all the assembly ops are skipped. On threaded builds, all the assembly ops are still executed. but once it reaches the op which compiles the regex, it notices that the regex is flagged as already compiled, throws away all the accumulated strings on the stack which make up the body of the stack, and uses the pre-compiled regex.

      Literal patten code blocks are compiled once at the same time the surrounding code is compiled, not when the pattern is compiled.

      Its a bug which needs fixing. The whole /o implementation is a bit rubbish at the moment.

      Dave.

[reply]
        It's much clearer now, much appreciated! 🙏🏻

        Op-Tree manipulation is indeed "creative".

        (I remember Merlyn complaining that the flip-flop was implemented in a similar way.)

        > Its a bug which needs fixing

        Well one could argue that a warning in combination with "injected" code should be enough, since it is such a rare combination. (Not sure if it's even possible to detect the interpolation of tied variables)

        OTOH /o is also meant to improve performance, and executing stuff which is thrown away certainly defies this purpose.

        I hope state isn't in the same trap of buggyness where the RHS is can have unexpected side effects on threaded Perl (???) °

        If not the mechanism might be repurposed to fix /o.

        Another, maybe easier, approach would be to semi-depricate/discourage /o by throwing a warning.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

        °) I should fire up Perlbrew to install a thread free Perl to run my experiments.

[reply]

In Section Seekers of Perl Wisdom