From friebel@ifh.de

Created by wolfgang.friebel@desy.de

Hi,

the mail on the same subject yesterday did not contain a correct email address
and also not my signature. Therefore I did not receive any notification.
Further information​:

In the script

# Author​: F Schrempp
$test='aaa';
$test='bbb' if $test =~ /aaa/;
$var = 'abc';
$tagnam = "";
while (<DATA>) {
  if (/SUBROUTINE/../END/){
  print "$tagnam\n" if defined $&;
  $tagnam=$&amp;;
  next if (!/$var/);
  }
}
close(DATA);
__END__
SUBROUTINE HVHBVI
PHEP
END

I studied the bug a little furter​: Obviously the heuristics for recognizing
.. as an iteration operator fails only, if the statements $var=..
and next if ... are inserted. Then the value of $& does not preserve its value
through the iterations and the $& from the outer scope is taken. This behaviour is in all new versions of perl I tested.

Wolfgang Friebel
  Deutsches Elektronen-Synchrotron DESY | Phone​: +49 33762 77372 |
  Platanenallee 6 | Fax​: +49 33762 77216 |
  D-15738 Zeuthen Germany | E-Mail​: friebel@​ifh.de or |
  | E-mail​: Wolfgang.Friebel@​desy.de |

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by friebel at Tue Apr 11 17:48:23 MET DST 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.6, archname=sun4-solaris-thread
    uname='sunos ilos 5.6 generic_105181-16 sun4u sparc sunw,ultra-4 '
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    usethreads=define use5005threads=define useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='cc', optimize='-O', gccversion=
    cppflags='-D_REENTRANT -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    ccflags ='-D_REENTRANT -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-L/usr/local/lib -R/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lposix4 -lpthread -lc -lcrypt -lsec
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /products/perl/5.6.0/lib/sun4-solaris-thread
    /products/perl/5.6.0/lib
    /products/perl/5.6.0/lib/site_perl/sun4-solaris-thread
    /products/perl/5.6.0/lib/site_perl
    /products/perl/5.6.0/lib/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/jupiter/friebel
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib
    LOGDIR (unset)
    PATH=/products/perl/5.6.0/bin:/home/jupiter/friebel/bin.SunOS_5:/home/jupiter/friebel/bin.SunOS:/home/jupiter/friebel/bin:/home/jupiter/friebel/scripts:/usr/sue/bin:/usr/bin:/usr/ucb:/usr/sbin:/opt/SUNWspro/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/local/X11/bin:/usr/local/bin:/usr/local/bin/scripts::.:/cern/pro/bin
    PERL_BADLANG (unset)
    SHELL=/bin/zsh

From @schwern

I confirm this bug in 5.5.4, 5.6.2, 5.8.6 and bleadperl.

From nobull@cpan.org

This should be merged with 3090 and the subject of both changed to
describe the actual issue.

The if(EXPR){BLOCK} construct instanciates a new scope on each iteration
and both EXPR and BLOCK are within that scope.

A failed regex does not update the last match context.

Considering these facts the observed behavoiur of the illustrative
script (on 5.8.4) is perfectly correct and does not illustrate a bug. As
far as I can see this is the same behavior that the original poster is
reporting as a bug so this should be flagged as not a bug or resolved.

The same behaviour can be seen more simply with a more "ordinary" match
variable and with an unconditional if.

Arguably if we get rid of the if(){} we do see a bug because a match
from one iteration of a loop is leaking through to the subsequent
interation. Strictly speaking this is a bug as most purposes each
iteration of the while() loop instanciates a new scope.

use strict;
use warnings;
use AtExit;
my $i;
print "$]\n";

print "With if () {}\n";
'outer' =~ /(.*)/;
$i=0;
while ( ++$i < 3 ) {
  print " pass $i\n";
  if (1) {
  print " before inner match \$1=$1\n";
  'inner' =~ /(.*)/;
  print " after inner match \$1=$1\n";
  }
  print " after inner block \$1=$1\n";
}

print "Without if () {}\n";
'outer' =~ /(.*)/;
$i=0;
while ( ++$i < 3 ) {
  print " pass $i\n";
  print " before inner match \$1=$1\n";
  'inner' =~ /(.*)/;
  print " after inner match \$1=$1\n";
  my $atexit = AtExit->new(sub{ print " end of scope\n" });
}
__END__
5.008004
With if () {}
  pass 1
  before inner match $1=outer
  after inner match $1=inner
  after inner block $1=outer
  pass 2
  before inner match $1=outer
  after inner match $1=inner
  after inner block $1=outer
Without if () {}
  pass 1
  before inner match $1=outer
  after inner match $1=inner
  end of scope
  pass 2
  before inner match $1=inner
  after inner match $1=inner
  end of scope

From nobull@cpan.org

This is also the same issue as is raised in 1833 so a "depends on" link
would be in order.

From @Hugmeir

On Sun Aug 19 13​:29​:04 2007, nobull@​cpan.org wrote​:

This is also the same issue as is raised in 1833 so a "depends on" link
would be in order.

Since https://rt-archive.perl.org/perl5/Ticket/Display.html?id=3090 is a duplicate
of this, and was marked as resolved, I vote to close this report.

@cpansprout - Status changed from 'open' to 'resolved'