in reply to is perl's regular expression engine reentrant ?

s/regex/replacement/e is re-entrant as far as the right-hand (replacement) expression is concerned. The regex engine itself has gotten better but isn't totally re-entrant yet but this only matters if you use experimental features to jump out to code from within the regex itself (left-hand side).

- tye        

Replies are listed 'Best First'.
Re^2: is perl's regular expression engine reentrant ? (works)
by plank (Novice) on Apr 27, 2007 at 01:18 UTC

    So I can do whatever I want on the "right side" with no undefined behaviour.

    Great news!

    I suppose you are saying that reentrancy is only an issue with ?{code} and ??{code} constructs.

    I knew these were problematic (and experimental features) but thought that making substitutions using the re engine on the evaluated code could also be a problem.

    Any idea where I can find documentation that mentions this explicitly

    Thank you.

      I suppose you are saying that reentrancy is only an issue with ?{code} and ??{code} constructs.

      This is in fact an issue. The following one-liner will segfault (with perl 5.8.8):

      perl -we '"_" =~ m{(??{"_" =~ /./})}'

        With the extensive rewrite of the regular expression engine, by dave_the_m and demerphq, that particular expression works just fine in the development version (what will become 5.10).

        % perl5.9.5 -wle 'print +("_" =~ m{(??{"_" =~ /./})}) ? 1 : 0' 0 % perl5.9.5 -wle 'print +("_" =~ m{(??{"_" !~ /./})}) ? 1 : 0' 1

        There exist, however, more exotic code constructs that will trip up reentrancy bugs.

        • another intruder with the mooring in the heart of the Perl

        Again thank you for clarifying this with an example. You have been most helpful.

        If I find any extra info regarding this I will try to append it top the question for future reference.