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

I am trying to come up with an answer (for my own edification) for someone's homework, but I am getting a panic from perl in the regex I am starting to develop.

My idea was to use (?{...code}) constructs in the regex to count each occurence of 'ab' in the string, and when the end of the string was encountered, do 'something' that made the regex match if the count was odd, and fail if the count was even. I haven' quite divined what that 'something' is yet, as my perl 5.8.2 on RH Linux 7.2 is doing a 

panic: top_env

[download]
when I try using the example from perlre 

#!/usr/bin/perl -w

use strict;

my $cnt;
my $res;

my $regex = qr/
           (?{ $cnt = 0 })        # Initialize $cnt.
           (?:                    # group only
           a
           (?{
           local $cnt = $cnt + 1; # Update $cnt, backtracking-safe.
           })
           )*
           aaaa
           (?{ $res = $cnt })     # success-copy to non-local var
           /x;

foreach my $line (<DATA>) {
    chomp $line;

    print STDERR "huzzah |$`| |$&| |$'| $res $line\n" if  $line =~ $re
+gex;
}

__DATA__
aaaaaaaa
aaaa

[download]

I've tracked it down to the  (?{local $cnt = $cnt + 1;}) part of the regex - remove that and the panic goes away.

I know the perlre says that (?{...code..}) is
WARNING: This extended regular expression feature is considered highly experimental, and may be changed or deleted without notice.
but I take that to mean experimental from a syntactic and semantic aspect, not nonoperational.

How does one begin to debug such an error ??

+++++++++++++++++
#!/usr/bin/perl
use warnings;use strict;use brain;

Replies are listed 'Best First'.
Re: (?{...code..}) regex construct causing panic: top_env in 5.8.2
by BrowserUk (Patriarch) on Feb 25, 2004 at 01:12 UTC

    local doesn't work on my'd vars, only globals. Change my $cnt; to our $cnt; and the panic goes away and your example runs fine.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Timing (and a little luck) are everything!
[reply]
[d/l]
[select]
      That is a good answer, but I think perl should not panic in this case, but point out the problem.

      -Mark

[reply]

        Agreed. And under normal code conditions it does. 

        { my $x; { local $x = 1 } };
Can't localize lexical variable $x at (eval 2) line 1, <> line 3.

        [download]

        Putting my "guess the reason" hat on, I could be that they try to keep the regex engine fast and so the error reporting from code blocks in regexes is lighter than elsewhere. Alternatively, it could be just that noone has raised the perlbug to casue it to get fixed yet.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        Timing (and a little luck) are everything!
[reply]
[d/l]
      ah, of course, probably would of worked that out with a little more info

      Can't localize lexical variable $cnt at ...

      +++++++++++++++++
      #!/usr/bin/perl
      use warnings;use strict;use brain;

[reply]
[d/l]
Re: (?{...code..}) regex construct causing panic: top_env in 5.8.2
by eyepopslikeamosquito (Archbishop) on Feb 25, 2004 at 12:34 UTC

    It would seem this area of perl is exceedingly difficult to fix, based on this bug (raised by the World's Greatest Perl golfer, I notice;-) in December 2002 and this one reported in March 2003 and this similar one (raised by someone who Ton used to beat over the head with his one iron at golf;-) reported in July 2003.

[reply]
Re: (?{...code..}) regex construct causing panic: top_env in 5.8.2
by Anonymous Monk on Feb 25, 2004 at 14:47 UTC
    Since you've found a bug, you should report it using perlbug. That way it might get fixed one day.
[reply]
Re: (?{...code..}) regex construct causing panic: top_env in 5.8.2
by ambrus (Abbot) on Feb 25, 2004 at 13:37 UTC

    Older perls can crash if the the regexp engine is called again from (?{...}). But this is not an older perl, and the regexp is not used again.

    These kind of problems are the reason why (?{...}) is still experimental.

[reply]
[d/l]
[select]
      So do newer perls, hence all the tomfoolery with forking in Regexp::Approx.
[reply]

Back to Seekers of Perl Wisdom