Closed p5pRT closed 19 years ago
--- begin sample script --- while (my $line = \) { if ($line =~ /Two/) { $line = "Dos\n"; redo; } print $line; }
__DATA__ One Two Three --- end sample script ---
outputs:
One Three
or\, with -w:
One Use of uninitialized value at test_redo.pl line 2\, \ chunk 2. Use of uninitialized value at test_redo.pl line 6\, \ chunk 2. Three
Using:
2c2\,3 \< while (my $line = \) { ---
my $line; while ($line = \) {
the output is:
One Two Three
as expected.
Perhaps that's the intended effect\, but I didn't find any reference to it in the docs.
This is a bug report for perl from khwilliamson@lucent.com\, generated with the help of perlbug 1.26 running under perl 5.00503.
The following program is an example:
use strict; my @A = ( 1\, 2\, 3); #my $i; while (my $i = shift @A) { print "i=$i\n"; last unless defined $i; redo; }
Different results occur if $i is declared outside the while statement (it works) than as shown above. The redo causes $i to become undefined.
Site configuration information for perl 5.00503:
Configured by expmake at Fri Sep 10 16:33:51 CDT 1999.
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris\, osvers=2.4\, archname=sun4-solaris uname='sunos nwpep 5.4 generic_101945-61 sun4d sparc ' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc'\, optimize='-O'\, gccversion= cppflags='' ccflags ='' 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 alignbytes=8\, usemymalloc=y\, prototype=define Linker and Libraries: ld='cc'\, ldflags ='' libpth=/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt 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'
Locally applied patches:
@INC for perl 5.00503: /opt/exp/perl/lib/5.00503/sun4-solaris /opt/exp/perl/lib/5.00503 /opt/exp/perl/lib/site_perl/5.005/sun4-solaris /opt/exp/perl/lib/site_perl/5.005 .
Environment for perl 5.00503: HOME=/home/khw LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib LOGDIR (unset) PATH=/usr/local/src/post/src/post:/home/khw/specbin:/home/khw/bin:/home/khw/print/bin:/usr/add-on/dwb/bin:/usr/5bin:/usr/ucb:/usr/add-on/local/bin:/usr/add-on/unison/bin:/opt/exp/bin:/usr/sbin:/usr/add-on/zmail/bin:/usr/add-on/ncmp/630/bin:/usr/add-on/SUNWspro/bin:/usr/openwin/bin:/usr/openwin/demo:/usr/bin/X11:/usr/add-on/ncmp/bin:/usr/ccs/bin:/etc:/usr/add-on/defty5/bin:/usr/add-on/tools/bin:/opt/exp/perl/bin: PERL_BADLANG (unset) SHELL=/bin/ksh
Probably related to this bug is another one with goto. It is definitely harmful here. It appears to undefine variables declared in a for (but not while) loop. The attached file is a short program illustrating it.
-- Karl Williamson Lucent Bell Labs 11900 Pecos St. Room 30G12 Westminster CO 80234
khwilliamson@lucent.com 303-538-4583 (same for fax\, press #)
#! perl -w
use strict;
my $i; #while(1) { for($i=0; $i \< 1; $i++) { my $var = 0; REDO: print STDERR '$var='\, $var\, "\n"; last unless defined $var; $var = 1; goto REDO; # Should cause infinite loop\, and does if the # 'for' is replaced with a 'while(1)' }
If "redo" happens in a while-loop where a lexical loop variable is declared in the while condition\, the variable becomes undefined. It should keep the value it had before "redo".
while ( my $line = \ ) { die "BAM!\n" unless defined $line; print "$line"; if ( $line =~ s/x// ) { redo; # when this hits\, $line becomes undefined. it shouldn't\, should it? # when "my $line" is put before the loop (and "my" deletd from the # condition) it works as expected. } } __DATA__ aaa bbb cccxx ddd
use strict; while( my $x = 1 ) { print "x is "\, (defined($x) ? $x : 'UNDEF')\, "\n"; redo; }
This emits the following output:
x is 1 x is UNDEF x is UNDEF ...
The first time through the loop\, $x is 1\, as one would expect. When the 'redo' branch is taken\, control is transferred to the top of the loop\, but the value in $x is destroyed.
I just stumbled over a problem similar to:
my $var = 5 if 0;
i.e. where runtime behaviour is unexpected. The example is:
my $flag; while (my $x = $flag + 1) { print "$x\n"; $flag++ or redo; last; }
this example should probably print 1 twice\, as $x is initialized to 1 in the first loop run and redo should not change it. ($flag is just used to make the problem stop).
However\, it prints "1" and an empty line\, i.e. the redo clears the my variable in the loop condition\, which *could* be a bug\, so I reported it. The behaviour seems to be consistent among 5.004\, 5.005\, 5.6 and 5.8.
On Sat\, Nov 30\, 2002 at 03:12:14PM -0000\, Marc Lehmann wrote:
----------------------------------------------------------------- [Please enter your report here]
I just stumbled over a problem similar to:
my $var = 5 if 0;
i.e. where runtime behaviour is unexpected. The example is:
my $flag; while (my $x = $flag + 1) { print "$x\n"; $flag++ or redo; last; }
this example should probably print 1 twice\, as $x is initialized to 1 in the first loop run and redo should not change it. ($flag is just used to make the problem stop).
However\, it prints "1" and an empty line\, i.e. the redo clears the my variable in the loop condition\, which *could* be a bug\, so I reported it. The behaviour seems to be consistent among 5.004\, 5.005\, 5.6 and 5.8.
I presume you've reduced your problem to the above case. I'm not quite sure why you didn't write it like this:
my $flag; while (my $x = 1) { print "$x\n"; $flag++ or redo; last; }
which also print "1" and an empty line. I don't see anything in that example that should ever cause $x to become undef\, so I think it has to be a bug.
my $flag; while (my $x = 1) { print "$x\n"; $flag++ or next; last; }
and
my $flag; while (my $x = 1) { print "$x\n"; $flag++ and last; }
both print "1" "1"
Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
On Sun\, Dec 01\, 2002 at 04:22:50PM -0000\, Nicholas Clark \perlbug@​perl\.org wrote:
I presume you've reduced your problem to the above case. I'm not quite sure why you didn't write it like this:
I can assure you it was just my disability to reduce it further. Your example is equivalent.
I don't see anything in that example that should ever cause $x to become undef\, so I think it has to be a bug.
Well\, the docs say that the conditional isn't evaluated again\, which means that the "my $x = " isn't evaluated again.
This could mean that $x isn't visible\, which isn't the case\, fortunately (and isn't desirable\, either\, I think).
$flag\+\+ or next;
both print "1" "1"
next\, however\, does reevaluate the condition\, so "my $x" is executed.
It boils down to wether "my $x" is compile or runtime. In fact\, it's both\, and I'd rather document this (e.g. as a programmer bug) than trying a fix that might slow down perl. Making it work is best though\, IMnsHO ;)
-- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_\,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Perhaps this perl-sample addresses the same problem?
This doesn't look right:
% perl -l while (my $x = $]) { die '$x undefined' unless defined $x; print $x; redo; } ^D 5.009 $x undefined at - line 3.
Goes back to at least 5.004 though.
Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 19765) configuration: Platform: osname=linux\, osvers=2.4.18-3\, archname=i586-linux uname='linux psdt.com 2.4.18-3 #1 thu apr 18 07:31:07 edt 2002 i586 unknown ' config_args='-des -Dusedevel' hint=recommended\, useposix=true\, d_sigaction=define usethreads=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='cc'\, ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm'\, optimize='-O2'\, cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion=''\, gccversion='2.96 20000731 (Red Hat Linux 7.3 2.96-113)'\, 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='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil -lrt perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil -lrt libc=/lib/libc-2.2.5.so\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-rdynamic' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Locally applied patches: DEVEL18374 Built under linux Compiled at Jun 13 2003 09:47:53 @INC: /usr/local/lib/perl5/5.9.0/i586-linux /usr/local/lib/perl5/5.9.0 /usr/local/lib/perl5/site_perl/5.9.0/i586-linux /usr/local/lib/perl5/site_perl/5.9.0 /usr/local/lib/perl5/site_perl . -- Peter Scott Pacific Systems Design Technologies
Warnings still show up in 5.6.0 and 5.8.0
I think some of us on irc.freenode.net's #perl have found a bug:
perl -we'my $i = 0; while (defined($_ = 62)) { print; $_ = 72; $i++; exit if $i == 3; redo; }' 627272
Why doesn't that print 626262? $_ isnt being reset to the value it had directly after the "while (defined($_ = 62)) {" code; it is staying at 72. Here is another example:
perl -wle'while (defined(my $foo = 1)) { die "foo is undef" unless defined $foo; redo }' foo is undef at -e line 1.
This action\, at the very least\, does not follow the principle of least surprise. If this is normal behavior\, then it isn't documented well.
Please contact me if there is anything I can do to help.
Thanks!
Chris Kelly Angell
On Tue\, Feb 10\, 2004 at 07:50:36PM -0000\, Chris Kelly wrote:
I think some of us on irc.freenode.net's #perl have found a bug:
perl -we'my $i = 0; while (defined($_ = 62)) { print; $_ = 72; $i++; exit if $i == 3; redo; }' 627272
Why doesn't that print 626262? $_ isnt being reset to the value it had directly after the "while (defined($_ = 62)) {" code; it is staying at 72.
The behavior is correct. From perldoc -f redo:
redo The "redo" command restarts the loop block without evaluating the conditional again.
redo() starts the loop over from the first statement *inside the block*. The conditional "defined($_ = 62)" will not be reexecuted. The idea is that you can redo that iteration of the loop.
If you remove the redo statement\, $_ = 62 will be executed and you'll get the behavior you expected.
perl -wle'while (defined(my $foo = 1)) { die "foo is undef" unless defined $foo; redo }' foo is undef at -e line 1.
This action\, at the very least\, does not follow the principle of least surprise. If this is normal behavior\, then it isn't documented well.
This one does feel like a bug\, or misfeature. Its probably a gotcha because of the dual nature of "my $foo = 1" having both compile-time and run-time effects.
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
\
The RT System itself - Status changed from 'new' to 'open'
Chris Kelly \perl5\-porters@​perl\.org writes:
# New Ticket Created by Chris Kelly # Please include the string: [perl #26521] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=26521 >
~s while loop and redo oddities; possible bug\, or badly documented behavior This is a bug report for perl from chris@bj21.com\, generated with the help of perlbug 1.34 running under perl v5.8.0.
----------------------------------------------------------------- [Please enter your report here]
I think some of us on irc.freenode.net's #perl have found a bug:
perl -we'my $i = 0; while (defined($_ = 62)) { print; $_ = 72; $i++; exit if $i == 3; redo; }' 627272
Why doesn't that print 626262? $_ isnt being reset to the value it had directly after the "while (defined($_ = 62)) {" code; it is staying at 72. Here is another example:
perldoc -f redo
redo LABEL redo The "redo" command restarts the loop block without evaluating the conditional again.
i.e. a sort of goto just-after-{
Hi Nick\,
Thanks for getting back to me on this subject.
I can't get to the trouble ticket I submitted (I forgot my username and password)\, though I remember my second example looked like this:
perl -le'while (my $foo = "bar") { die "\$foo is undef" unless defined $foo; print $foo; redo }'
Here are the results of the command:
bar $foo is undef at -e line 1.
Take away the my() and the loop runs indefinitely. I still believe this behavior is odd\, or poorly documented.
Thanks Nick\,
Chris Kelly
+-----------------------------+ Christopher Kelly Web Developer\, Pi Yee Press 4855 W. Nevso Drive Las Vegas\, NV 89103 chris@piyeepress.com Office - (702) 579-7711 Fax - (702) 579-BOOK +-----------------------------+
On Thu\, 19 Feb 2004\, Nick Ing-Simmons via RT wrote:
Chris Kelly \perl5\-porters@​perl\.org writes:
# New Ticket Created by Chris Kelly # Please include the string: [perl #26521] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=26521 >
~s while loop and redo oddities; possible bug\, or badly documented behavior This is a bug report for perl from chris@bj21.com\, generated with the help of perlbug 1.34 running under perl v5.8.0.
----------------------------------------------------------------- [Please enter your report here]
I think some of us on irc.freenode.net's #perl have found a bug:
perl -we'my $i = 0; while (defined($_ = 62)) { print; $_ = 72; $i++; exit if $i == 3; redo; }' 627272
Why doesn't that print 626262? $_ isnt being reset to the value it had directly after the "while (defined($_ = 62)) {" code; it is staying at 72. Here is another example:
perldoc -f redo
redo LABEL redo The "redo" command restarts the loop block without evaluating the conditional again.
i.e. a sort of goto just-after-{
Chris Kelly \chris@​piyeepress\.com writes:
Hi Nick\,
Thanks for getting back to me on this subject.
I can't get to the trouble ticket I submitted (I forgot my username and password)\, though I remember my second example looked like this:
perl -le'while (my $foo = "bar") { die "\$foo is undef" unless defined $foo; print $foo; redo }'
Here are the results of the command:
bar $foo is undef at -e line 1.
Take away the my() and the loop runs indefinitely. I still believe this behavior is odd\, or poorly documented.
Yes - your 2nd example does seem to be a bug. If redo is goto { then it should NOT do the undef implied by the }
Thanks Nick\,
Chris Kelly
+-----------------------------+ Christopher Kelly Web Developer\, Pi Yee Press 4855 W. Nevso Drive Las Vegas\, NV 89103 chris@piyeepress.com Office - (702) 579-7711 Fax - (702) 579-BOOK +-----------------------------+
On Thu\, 19 Feb 2004\, Nick Ing-Simmons via RT wrote:
Chris Kelly \perl5\-porters@​perl\.org writes:
# New Ticket Created by Chris Kelly # Please include the string: [perl #26521] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=26521 >
~s while loop and redo oddities; possible bug\, or badly documented behavior This is a bug report for perl from chris@bj21.com\, generated with the help of perlbug 1.34 running under perl v5.8.0.
----------------------------------------------------------------- [Please enter your report here]
I think some of us on irc.freenode.net's #perl have found a bug:
perl -we'my $i = 0; while (defined($_ = 62)) { print; $_ = 72; $i++; exit if $i == 3; redo; }' 627272
Why doesn't that print 626262? $_ isnt being reset to the value it had directly after the "while (defined($_ = 62)) {" code; it is staying at 72. Here is another example:
perldoc -f redo
redo LABEL redo The "redo" command restarts the loop block without evaluating the conditional again.
i.e. a sort of goto just-after-{
[khw@bighorn.dr.lucent.com - Fri Feb 25 02:35:04 2000]:
This is a bug report for perl from khwilliamson@lucent.com\, generated with the help of perlbug 1.26 running under perl 5.00503.
----------------------------------------------------------------- The following program is an example:
use strict; my @A = ( 1\, 2\, 3); #my $i; while (my $i = shift @A) { print "i=$i\n"; last unless defined $i; redo; }
Different results occur if $i is declared outside the while statement (it works) than as shown above. The redo causes $i to become undefined.
This does not appear to be a bug. Quoting "Programming Perl\, Second Edition"\, "The redo command restarts the loop block without evaluating the conditional again." So\, when it re-enters the block\, the shift is not performed and $i is implicitly defined to undef and the previous value is lost. The correct thing to do is to declare the variable outside of the loop conditional\, or initialize $i within the block.
while (@A) { my $i = shift @A; print "i=$i\n"; last unless defined $i; # redo; or just }
}
@smpeters - Status changed from 'open' to 'resolved'
Steve Peters wrote:
This does not appear to be a bug. Quoting "Programming Perl\, Second Edition"\, "The redo command restarts the loop block without evaluating the conditional again." So\, when it re-enters the block\, the shift is not performed and $i is implicitly defined to undef and the previous value is lost.
If your interpretation of this is correct then I think the documentation should be changed to clarify the point. I wouldn't have expected this result from that description. In fact that description makes me think that
my @a=(2..5); while (my $x=shift @a) { print $x\,"\n"; redo if $x--; }
and
my @a=(2..5); while (my $x=shift @a) { STARTBLOCK: print $x\,"\n"; goto STARTBLOCK if $x--; }
should be equivelent\, but by your reading they aren't.
Cheers\, Yves
On Wed\, Dec 08\, 2004 at 10:38:37AM -0000\, Orton\, Yves wrote:
Steve Peters wrote:
This does not appear to be a bug. Quoting "Programming Perl\, Second Edition"\, "The redo command restarts the loop block without evaluating the conditional again." So\, when it re-enters the block\, the shift is not performed and $i is implicitly defined to undef and the previous value is lost.
If your interpretation of this is correct then I think the documentation should be changed to clarify the point. I wouldn't have expected this result from that description. In fact that description makes me think that
my @a=(2..5); while (my $x=shift @a) { print $x\,"\n"; redo if $x--; }
and
my @a=(2..5); while (my $x=shift @a) { STARTBLOCK: print $x\,"\n"; goto STARTBLOCK if $x--; }
should be equivelent\, but by your reading they aren't.
I'm with Yves on this one.
-- Thank God I'm an atheist.....
Dave Mitchell wrote:
If your interpretation of this is correct then I think the documentation should be changed to clarify the point. I wouldn't have expected this result from that description. In fact that description makes me think that
my @a=(2..5); while (my $x=shift @a) { print $x\,"\n"; redo if $x--; }
and
my @a=(2..5); while (my $x=shift @a) { STARTBLOCK: print $x\,"\n"; goto STARTBLOCK if $x--; }
should be equivelent\, but by your reading they aren't.
I'm with Yves on this one.
It occurred to me that there is another reason to not agree with the proposed interpretation. It means that redo in for loops and while loops do different things:
my @a=(2..5); for my $x (@a) { print $x\,"\n"; redo if $x--; }
In this case the $x doesn't suddenly become undef after the redo....
IMO the reported bug is indeed a bug.
Cheers\, Yves
@smpeters - Status changed from 'resolved' to 'open'
[yves.orton@de.mci.com - Wed Dec 08 11:02:33 2004]:
Dave Mitchell wrote:
If your interpretation of this is correct then I think the documentation should be changed to clarify the point. I wouldn't have expected this result from that description. In fact that description makes me think that
my @a=(2..5); while (my $x=shift @a) { print $x\,"\n"; redo if $x--; }
and
my @a=(2..5); while (my $x=shift @a) { STARTBLOCK: print $x\,"\n"; goto STARTBLOCK if $x--; }
should be equivelent\, but by your reading they aren't.
I'm with Yves on this one.
It occurred to me that there is another reason to not agree with the proposed interpretation. It means that redo in for loops and while loops do different things:
my @a=(2..5); for my $x (@a) { print $x\,"\n"; redo if $x--; }
In this case the $x doesn't suddenly become undef after the redo....
IMO the reported bug is indeed a bug.
Reopened :)
while (my $a = \
When you do the redo\, it doesn't execute the \
redo should goto something between the loop-initialiser and the loop-body. Executing a part of the initializer is a bug.
Ben Mankin (via RT) wrote:
# New Ticket Created by Ben Mankin # Please include the string: [perl #33776] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=33776 >
This is a bug report for perl from shevek@silver.wordmap.local\, generated with the help of perlbug 1.34 running under perl v5.8.3.
----------------------------------------------------------------- [Please enter your report here]
while (my $a = \
) { .... $a = "bar"; redo; ... } When you do the redo\, it doesn't execute the \
but it does execute the 'my $a' and thus clears $a. redo should goto something between the loop-initialiser and the loop-body. Executing a part of the initializer is a bug.
#!/usr/bin/perl use strict; use warnings;
my $i = 0; while (my $a = \) { print $a; $a = "bar\n"; redo if ++$i \< 5; }
__DATA__ abc def ghi
>>> output:
abc Use of uninitialized value in print at test.pl line 9\, \ line 1. bar bar bar def ghi
#!/usr/bin/perl use strict; use warnings;
my $i = 0; my $a; # goes away when declared before loop while ($a = \) { print $a; $a = "bar\n"; redo if ++$i \< 5; }
__DATA__ abc def ghi
>>> output:
abc bar bar bar bar def ghi
The RT System itself - Status changed from 'new' to 'open'
my $i = 0; my $a; # goes away when declared before loop while ($a = \) { print $a; $a = "bar\n"; redo if ++$i \< 5; }
Its still a bug even though its easy to work around. Id say the following from perlsyn:
"The redo command restarts the loop block without evaluating the conditional again. The continue block\, if any\, is not executed. This command is normally used by programs that want to lie to themselves about what was just input."
says that the following should be functionally identical:
while (EXPR) { MAGIC_LABEL: BODY; goto MAGIC_LABEL if COND; }
while (EXPR) { BODY; redo if COND; }
But if EXPR is "my $foo=func()" there is no way to lie to themselves about what was just input. So IMO this is a bug. If its not then perlsyn should be changed to specifically note that you can't do this with lexical declarations in the EXPR part.
Yves
[lektu@teleline.es - Wed Jan 26 19:13:55 2000]: --- begin sample script --- while (my $line = \) { if ($line =~ /Two/) { $line = "Dos\n"; redo; } print $line; }
__DATA__ One Two Three --- end sample script ---
outputs:
One Three
or\, with -w:
One Use of uninitialized value at test_redo.pl line 2\, \ chunk 2. Use of uninitialized value at test_redo.pl line 6\, \ chunk 2. Three
Using:
2c2\,3 \< while (my $line = \) { ---
my $line; while ($line = \) {
the output is:
One Two Three
as expected.
Perhaps that's the intended effect\, but I didn't find any reference to it in the docs.
OK\, I've merged together all the related tickets for this problem. This apparent bug has been open for over five years. Obviously\, there is a simple work around\, but this really should be resolved. I'd like to discuess whether this is truly a bug or not. The main issue is whether the lexical variable should live past the redo. Any thoughts?
I'm not sure which bug report of mine you are referring to. The only similar thing I can find is that "goto confuses redo". Is that the one you mean?
If so\, I don't think it should be grouped with this one. It may stem from the same place in the internals\, but from a user's point of view it is quite different.
On Mon\, Apr 25\, 2005 at 10:05:16PM -0400\, Mark Jason Dominus wrote:
I'm not sure which bug report of mine you are referring to. The only similar thing I can find is that "goto confuses redo". Is that the one you mean?
If so\, I don't think it should be grouped with this one. It may stem from the same place in the internals\, but from a user's point of view it is quite different.
Mark\,
Your ticket was titled "redo' destroys value of lexical loop variable" with the example code of
use strict; while( my $x = 1 ) { print "x is "\, (defined($x) ? $x : 'UNDEF')\, "\n"; redo; }
This emits the following output:
x is 1 x is UNDEF x is UNDEF
On 26 Apr 2005 01:46:02 -0000\, Steve Peters via RT \perlbug\-followup@​perl\.org wrote:
[lektu@teleline.es - Wed Jan 26 19:13:55 2000]: --- begin sample script --- while (my $line = \) { if ($line =~ /Two/) { $line = "Dos\n"; redo; } print $line; }
__DATA__ One Two Three --- end sample script ---
outputs:
One Three
or\, with -w:
One Use of uninitialized value at test_redo.pl line 2\, \ chunk 2. Use of uninitialized value at test_redo.pl line 6\, \ chunk 2. Three
Using:
2c2\,3 \< while (my $line = \) { ---
my $line; while ($line = \) {
the output is:
One Two Three
as expected.
Perhaps that's the intended effect\, but I didn't find any reference to it in the docs.
OK\, I've merged together all the related tickets for this problem. This apparent bug has been open for over five years. Obviously\, there is a simple work around\, but this really should be resolved. I'd like to discuess whether this is truly a bug or not. The main issue is whether the lexical variable should live past the redo. Any thoughts?
This is definately a bug. The docs are pretty clear that redo should be equivelent to a goto label at the start of the block:
IE:
{ foo(); redo if $x; }
should be the functionally equivelent to
{ START_OF_BLOCK: foo(); goto START_OF_BLOCK if $x; }
which i think makes it pretty clear that the redo causing the lexical variable to go to undef is not correct.
There is also the following line from perlsyn:
"The redo command restarts the loop block without evaluating the conditional again. The continue block\, if any\, is not executed. This command is normally used by programs that want to lie to themselves about what was just input."
Having the variable set to undef completely blows the ability of the program to lie to itself so either the documentation is wrong and this isnt a bug\, or the documentation is correct and this is a bug. I go for the latter and consider this to be a bug.
Cheers\, yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
On Tue\, Apr 26\, 2005 at 01:46:02AM -0000\, Steve Peters via RT wrote:
OK\, I've merged together all the related tickets for this problem. This apparent bug has been open for over five years. Obviously\, there is a simple work around\, but this really should be resolved. I'd like to discuess whether this is truly a bug or not. The main issue is whether the lexical variable should live past the redo. Any thoughts?
This bug has now annoyed me sufficiently that I've fixed it :-)
Change #24412.
Basically for any while()\, until() or for(;;) loop that has a my in the conditional (actually an our will trigger it too)\, an extra scope is added to the body\, ie an enter/leave op pair. Then pp_redo() has been modified so that if the redo op is an enter\, then one less context is popped\, and control is passed to the op *after* the enter. Which makes redo about equivalent to a goto TOP.
Dave.
-- Spock (or Data) is fired from his high-ranking position for not being able to understand the most basic nuances of about one in three sentences that anyone says to him. -- Things That Never Happen in "Star Trek" #19
In article \20050507133207\.GI4731@​iabyn\.com\, Dave Mitchell \davem@​iabyn\.com writes:
Basically for any while()\, until() or for(;;) loop that has a my in the conditional (actually an our will trigger it too)\, an extra scope is added to the body\, ie an enter/leave op pair. Then pp_redo() has been modified so that if the redo op is an enter\, then one less context is popped\, and control is passed to the op *after* the enter. Which makes redo about equivalent to a goto TOP.
Dave.
wouldn't that notably slow down relatively common constructs like:
while(my $process = shift @array) { ... }
?
On Sat\, May 07\, 2005 at 03:33:54PM +0000\, Ton Hospel wrote:
In article \20050507133207\.GI4731@​iabyn\.com\, Dave Mitchell \davem@​iabyn\.com writes:
Basically for any while()\, until() or for(;;) loop that has a my in the conditional (actually an our will trigger it too)\, an extra scope is added to the body\, ie an enter/leave op pair. Then pp_redo() has been modified so that if the redo op is an enter\, then one less context is popped\, and control is passed to the op *after* the enter. Which makes redo about equivalent to a goto TOP.
Dave.
wouldn't that notably slow down relatively common constructs like:
while(my $process = shift @array) { ... }
A little bit. Less than than adding a bare block to the loop.
-- Never do today what you can put off till tomorrow.
@smpeters - Status changed from 'open' to 'resolved'
@mjdominus - Status changed from 'resolved' to 'open'
@smpeters - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#2049 (status was 'resolved')
Searchable as RT2049$