From @Juerd

Created by @Juerd

2;0 juerd@​ouranos​:~$ perl -le'for(my $i = 5;0;1) { } print $i'

2;0 juerd@​ouranos​:~$ perl -MO=Deparse -le'for(my $i = 5;0;1) { } print $i' | perl
-e syntax OK
5

Deparse simplifies the loop, but gets scoping wrong when it does that​:

2;0 juerd@​ouranos​:~$ perl -MO=Deparse -le'for(my $i = 5;0;1) { } print $i'
BEGIN { $/ = "\n"; $\ = "\n"; }
my $i = 5;
print $i;
-e syntax OK

Flags:
    category=library
    severity=medium

Site configuration information for perl v5.8.0:

Configured by root at Mon Mar 24 20:36:06 CET 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.19-gentoo-r10, archname=i686-linux
    uname='linux ouranos 2.4.19-gentoo-r10 #3 sun jan 5 22:38:08 cet 2003 i686 amd athlon(tm) processor authenticamd gnulinux '
    config_args='-des -Darchname=i686-linux -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dlocincpth=  -Doptimize=-O2 -march=athlon-tbird -pipe -fomit-frame-pointer  -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman3ext=3pm -Dcf_by=Gentoo -Ud_csh -Di_gdbm -Di_db -Di_ndbm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL5 -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -march=athlon-tbird -pipe -fomit-frame-pointer ',
    cppflags='-DPERL5 -DPERL5 -fno-strict-aliasing'
    ccversion='', gccversion='3.2.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lpthread -lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
    perllibs=-lpthread -lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.3.1.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.1'
  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 v5.8.0:
    /usr/lib/perl5/5.8.0/i686-linux
    /usr/lib/perl5/5.8.0
    /usr/lib/perl5/site_perl/5.8.0/i686-linux
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl/5.6.1
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.0/i686-linux
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    .


Environment for perl v5.8.0:
    HOME=/home/juerd
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/bin:/usr/bin:/bin:/usr/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.2:/usr/X11R6/bin:/opt/blackdown-jdk-1.3.1/bin:/opt/blackdown-jdk-1.3.1/jre/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/games/bin:/opt/vmware/bin:/var/qmail/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From smcc@mit.edu

"Juerd" == Juerd (via RT) writes​:

Juerd> This is a bug report for perl from juerd@​cpan.org, generated
Juerd> with the help of perlbug 1.34 running under perl v5.8.0.

Juerd> -----------------------------------------------------------------
Juerd> [Please enter your report here]

Juerd> Deparse simplifies the loop, but gets scoping wrong when it
Juerd> does that​:

Juerd> $ perl -MO=Deparse -le'for(my $i = 5;0;1) { } print $i'
Juerd> BEGIN { $/ = "\n"; $\ = "\n"; }
Juerd> my $i = 5;
Juerd> print $i;
Juerd> -e syntax OK

The simplifying is actually being done by perl before B​::Deparse sees
the program, but the simplification is what causes Deparse to miss the
scoping.

Looking at the OP tree, you can see that almost nothing remains of the
original for loop structure​:

% perl -MO=Concise -e 'for (my $i = 5;0;) {} exit'
9 <@​> leave[$i​:1,3] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 3 -e​:1) v ->3
5 <2> sassign vKS/2 ->6
3 <$> const[IV 5] s ->4
4 <0> padsv[$i​:1,3] sRM*/LVINTRO ->5
6 <;> nextstate(main 3 -e​:1) v ->7
7 <;> nextstate(main 4 -e​:1) v ->8
8 <0> exit v ->9

For comparison,

% perl -MO=Concise -e 'my $i = 5; exit'
8 <@​> leave[$i​:1,2] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v ->3
5 <2> sassign vKS/2 ->6
3 <$> const[IV 5] s ->4
4 <0> padsv[$i​:1,2] sRM*/LVINTRO ->5
6 <;> nextstate(main 2 -e​:1) v ->7
7 <0> exit v ->8

The only differences are the extra nextstate in the ex-for case, and
the COP sequence numbers which represent the scope information (the
1,2 or 1,3 in the padsv OP, corresponding to numbers in the nextstate
OPs; note that the [$i​:1,2] in the leave is a bug in Concise). Most of
the time, B​::Concise gets away without looking at the COP sequence
numbers, since if you just print the declarations in the same places
they occurred in the original code, they'll get the right scope. That
doesn't work here because the scope has been optimized away without
leaving any structural trace (e.g., no OP_SCOPE).

This could probably be fixed by another special case in lineseq(),
perhaps right next to the check that connects the initializations of
real for(;;) loops with their bodies. Of hand, I can't think of
another way you'd get consecutive nextstates, so that might be a good
thing to check for.

-- Stephen

From @jkeenan

On Thu May 01 23​:12​:03 2003, smcc wrote​:

"Juerd" == Juerd (via RT) writes​:

Juerd> This is a bug report for perl from juerd@​cpan.org, generated
Juerd> with the help of perlbug 1.34 running under perl v5.8.0.

Juerd> -----------------------------------------------------------------
Juerd> [Please enter your report here]

Juerd> Deparse simplifies the loop, but gets scoping wrong when it
Juerd> does that​:

Juerd> $ perl -MO=Deparse -le'for(my $i = 5;0;1) { } print $i'
Juerd> BEGIN { $/ = "\n"; $\ = "\n"; }
Juerd> my $i = 5;
Juerd> print $i;
Juerd> -e syntax OK

The simplifying is actually being done by perl before B​::Deparse sees
the program, but the simplification is what causes Deparse to miss the
scoping.

Looking at the OP tree, you can see that almost nothing remains of the
original for loop structure​:

% perl -MO=Concise -e 'for (my $i = 5;0;) {} exit'
9 <@​> leave[$i​:1,3] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 3 -e​:1) v ->3
5 <2> sassign vKS/2 ->6
3 <$> const[IV 5] s ->4
4 <0> padsv[$i​:1,3] sRM*/LVINTRO ->5
6 <;> nextstate(main 3 -e​:1) v ->7
7 <;> nextstate(main 4 -e​:1) v ->8
8 <0> exit v ->9

For comparison,

% perl -MO=Concise -e 'my $i = 5; exit'
8 <@​> leave[$i​:1,2] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e​:1) v ->3
5 <2> sassign vKS/2 ->6
3 <$> const[IV 5] s ->4
4 <0> padsv[$i​:1,2] sRM*/LVINTRO ->5
6 <;> nextstate(main 2 -e​:1) v ->7
7 <0> exit v ->8

The only differences are the extra nextstate in the ex-for case, and
the COP sequence numbers which represent the scope information (the
1,2 or 1,3 in the padsv OP, corresponding to numbers in the nextstate
OPs; note that the [$i​:1,2] in the leave is a bug in Concise). Most of
the time, B​::Concise gets away without looking at the COP sequence
numbers, since if you just print the declarations in the same places
they occurred in the original code, they'll get the right scope. That
doesn't work here because the scope has been optimized away without
leaving any structural trace (e.g., no OP_SCOPE).

This could probably be fixed by another special case in lineseq(),
perhaps right next to the check that connects the initializations of
real for(;;) loops with their bodies. Of hand, I can't think of
another way you'd get consecutive nextstates, so that might be a good
thing to check for.

-- Stephen

Do people believe that there is a problem here which needs fixing?

Thank you very much.
Jim Keenan

From @ap

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-09-28 04​:05]​:

Do people believe that there is a problem here which needs fixing?

I do. It seems to have bitten almost no one so it may go unfixed for
another decade, but it is clearly broken so the ticket should stay.