Perl bug: Incorrect handling of $1 in first pass in (?{ code })

[p5pRT]

Migrated from rt.perl.org#5030 (status was 'resolved')

Searchable as RT5030$

[p5pRT]

From ttel5535@ss1000.ms.mff.cuni.cz

The $1 variable is not correctly set in the first (and matching) pass in the
(?{ code }). See the following example​:

#!/usr/bin/perl

# Try uncomment this
#"q" =~ m{ ^(q) (?{}) }x;

for ("a​:", "b​: ", "c​:") {

  if ( m{
  ([a-z])
  (?{
  printf "Inside​:\n";
  printf '$^R' . " == $^R\n";
  printf '$1' . " == $1\n";
  $1; # this establishes the $^R value for the first cycle
  # at least outside,
  # during other cycles it is established as it should
  # (also in "At the end" section)
  })
  :$
  (?{
  printf "At the end​:\n";
  printf '$^R' . " == $^R\n";
  printf '$1' . " == $1\n";
  })
  }x
  )
  {
  printf "Outside​:\n";
  printf '$^R' . " == $^R\n";
  printf '$1' . " == $1\n";
  printf "\n"
  }
}

####### end of example #######

Actual output​:

~/pokus/perl> bug
Inside​:
$^R ==
$1 ==
At the end​:
$^R ==
$1 ==
Outside​:
$^R == 1
$1 == a

Inside​:
$^R == 1
$1 == c
At the end​:
$^R == c
$1 == c
Outside​:
$^R == 1
$1 == c

What I would expect​:
~/pokus/perl> bug
Inside​:
$^R ==
$1 == a
At the end​:
$^R == a
$1 == a
Outside​:
$^R == 1
$1 == a

Inside​:
$^R == 1
$1 == c
At the end​:
$^R == c
$1 == c
Outside​:
$^R == 1
$1 == c

I would also expect that there will be the "Inside" section for string "b​: "
although it does not match, but the "Inside" section is (by my opinion)
executed before perl guess it​:

Inside​:
$^R == 1
$1 == b
Inside​:
$^R == 1
$1 == c
...

But this is probably not a bug.

  Thank you
 
  Tomas Telensky

Perl Info

Site configuration information for perl 5.00503:

Configured by root at Mon Aug 30 23:08:56 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.2.5-22smp, archname=i386-linux
    uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 09:11:51 edt 1999 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lposix -lcrypt
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/lib/perl5/5.00503/i386-linux
    /usr/lib/perl5/5.00503
    /usr/lib/perl5/site_perl/5.005/i386-linux
    /usr/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/root
    LANG=en_US
    LANGUAGE (unset)
    LC_ALL=
    LC_CTYPE=cs_CZ
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=.:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From @mjdominus

The $1 variable is not correctly set in the first (and matching) pass in the
(?{ code }). See the following example​:

This has been fixed in 5.6.0.

Thanks for your bug report.

[p5pRT]

From [Unknown Contact. See original ticket]

The $1 variable is not correctly set in the first (and matching) pass
in the (?{ code }). See the following example​:

Well spotted. This bug has been fixed in recent perls -- the output my
5.6.0 shows is identical to your expected output. I believe it was patch
#2372 which fixed this, but I am far from sure.

I would also expect that there will be the "Inside" section for string
"b​: " although it does not match, but the "Inside" section is (by my
opinion) executed before perl guess it​:

Inside​:
$^R == 1
$1 == b
Inside​:
$^R == 1
$1 == c
...

But this is probably not a bug.

And you're right that this is not a bug. It's the REx optimizer stopping
the show before the ?{} sections can be run. This is a confusing enough
fact that I might argue to have optimizations turned off whenever a ?{}
or ??{} is present. But I doubt it would fly.

Is this something that needs more specific documenting? I patched retut
to mention this a while ago, but it's sort of buried.

-dlc