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

I tried your code on "unthreaded" perl and it prints twice. It seems like this weird "interpolation" ° resolves to "x1" =~ /x1/ which doesn't make much sense as a bug demo.

On a perl interpreter compiled without threads support it prints "doing arg" once; on a threaded perl interpreter it prints twice - see the example run below. The match itself works correctly in both cases: it resolves to /x1/. My example was to show that there are strange side-effects which depend on the particlar perl interpreter you run it under. There are other edge case effects, the details of which I can't recall off the top of my head.

$ perl5420 -v This is perl 5, version 42, subversion 0 (v5.42.0) built for x86_64-li +nux $ perl5420 ~/tmp/p doing arg match match $ perl5420t -v This is perl 5, version 42, subversion 0 (v5.42.0) built for x86_64-li +nux-thread-multi $ perl5420t ~/tmp/p doing arg match doing arg match $

Dave.

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

Replies are listed 'Best First'.
Re^18: Reusing a complex regexp in multiple spots, escaping the regexp
by LanX (Saint) on Apr 17, 2026 at 15:13 UTC
    Thanks for the clarification. °

    Honestly, when injecting code evaluation into a variable interpolation, I'm not surprised to get inconsistent side effects.

    It would be of bigger concern if it also happened with more "official" means like (?{...}) or (??{...})

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

    °) how popular are Perl builds without thread support?

      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]/; }
      will, on threaded builds, invoke both $tied_array->FETCH(0) and $tied_array->FETCH(1), but will discard the second value.

      Dave.

        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