Re^20: Reusing a complex regexp in multiple spots, escaping the regexp

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}

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

Replies are listed 'Best First'.
Re^21: Reusing a complex regexp in multiple spots, escaping the regexp by dave_the_m (Monsignor) on Apr 18, 2026 at 12:30 UTC
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]
Re^22: Reusing a complex regexp in multiple spots, escaping the regexp by LanX (Saint) on Apr 18, 2026 at 13:47 UTC
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]
Re^23: Reusing a complex regexp in multiple spots, escaping the regexp by dave_the_m (Monsignor) on Apr 18, 2026 at 16:07 UTC
state is implemented sensibly. The /o implementation needs updating to behave like state. It's a hacky leftover from when the perl internals were first altered to be thread-safe. Dave.	[reply]