-
Notifications
You must be signed in to change notification settings - Fork 575
redo doesn't like lexical vars defined in while test #1095
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
From lektu@teleline.es--- begin sample script --- __DATA__ outputs: One or, with -w: One Using: 2c2,3
the output is: One as expected. Perhaps that's the intended effect, but I didn't find any Perl Info
|
From khw@bighorn.dr.lucent.comThis is a bug report for perl from khwilliamson@lucent.com, The following program is an example: use strict; Different results occur if $i is declared outside the while 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: Locally applied patches: @INC for perl 5.00503: Environment for perl 5.00503: |
From @khwilliamsonProbably related to this bug is another one with goto. It is definitely -- khwilliamson@lucent.com |
From @khwilliamson#! perl -w use strict; my $i; |
From anno4000@lublin.zrz.tu-berlin.deCreated by anno4000@lublin.zrz.tu-berlin.deIf "redo" happens in a while-loop where a lexical loop variable while ( my $line = <DATA> ) { Perl Info
|
From @mjdominusCreated by @mjdominus use strict; This emits the following output: x is 1 The first time through the loop, $x is 1, as one would expect. Perl Info
|
From pcg@goof.comCreated by root@cerebro.laendleI just stumbled over a problem similar to: my $var = 5 if 0; i.e. where runtime behaviour is unexpected. The example is: my $flag; this example should probably print 1 twice, as $x is initialized to 1 in However, it prints "1" and an empty line, i.e. the redo clears the my Perl Info
|
From @nwc10On Sat, Nov 30, 2002 at 03:12:14PM -0000, Marc Lehmann wrote:
I presume you've reduced your problem to the above case. I'm not quite sure my $flag; which also print "1" and an empty line. my $flag; and my $flag; both print "1" "1" Nicholas Clark |
From pcg@goof.comOn Sun, Dec 01, 2002 at 04:22:50PM -0000, Nicholas Clark <perlbug@perl.org> wrote:
I can assure you it was just my disability to reduce it further. Your
Well, the docs say that the conditional isn't evaluated again, which means This could mean that $x isn't visible, which isn't the case, fortunately
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, -- |
From guest@guest.guest.xxxxxxxxPerhaps this perl-sample addresses the same problem? |
From @pjscottThis doesn't look right: % perl -l Goes back to at least 5.004 though. Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 19765) Characteristics of this binary (from libperl): |
From ziggy@panix.comWarnings still show up in 5.6.0 and 5.8.0 |
From chris@mail.piyeepress.comCreated by chris@bj21.comI 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; }' 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 }' 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 Perl Info
|
From @schwernOn Tue, Feb 10, 2004 at 07:50:36PM -0000, Chris Kelly wrote:
The behavior is correct. From perldoc -f redo: redo The "redo" command restarts the loop block without evaluating redo() starts the loop over from the first statement *inside the block*. If you remove the redo statement, $_ = 62 will be executed and you'll get
This one does feel like a bug, or misfeature. Its probably a gotcha -- |
The RT System itself - Status changed from 'new' to 'open' |
From nick.ing-simmons@elixent.comChris Kelly <perl5-porters@perl.org> writes:
perldoc -f redo redo LABEL i.e. a sort of goto just-after-{ |
From chris@piyeepress.comHi 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 perl -le'while (my $foo = "bar") { die "\$foo is undef" unless defined Here are the results of the command: bar Take away the my() and the loop runs indefinitely. I still believe this Thanks Nick, Chris Kelly +-----------------------------+ On Thu, 19 Feb 2004, Nick Ing-Simmons via RT wrote:
|
From nick.ing-simmons@elixent.comChris Kelly <chris@piyeepress.com> writes:
Yes - your 2nd example does seem to be a bug.
|
From @smpeters
This does not appear to be a bug. Quoting "Programming Perl, Second while (@A) {
|
@smpeters - Status changed from 'open' to 'resolved' |
From @demerphqSteve Peters wrote:
If your interpretation of this is correct then I think the documentation my @a=(2..5); and my @a=(2..5); should be equivelent, but by your reading they aren't. Cheers, |
From @iabynOn Wed, Dec 08, 2004 at 10:38:37AM -0000, Orton, Yves wrote:
I'm with Yves on this one. -- |
From @demerphqDave Mitchell wrote:
It occurred to me that there is another reason to not agree with the my @a=(2..5); In this case the $x doesn't suddenly become undef after the redo.... IMO the reported bug is indeed a bug. Cheers, |
@smpeters - Status changed from 'resolved' to 'open' |
From @smpeters
Reopened :) |
From ben.mankin@wordmap.comCreated by shevek@silver.wordmap.localwhile (my $a = <FH>) { .... $a = "bar"; redo; ... } When you do the redo, it doesn't execute the <FH> but it does redo should goto something between the loop-initialiser and the Perl Info
|
From RandyS@ThePierianSpring.orgBen Mankin (via RT) wrote:
#!/usr/bin/perl my $i = 0; __DATA__ >>> output: abc #!/usr/bin/perl my $i = 0; __DATA__ >>> output: abc |
The RT System itself - Status changed from 'new' to 'open' |
From @demerphq
Its still a bug even though its easy to work around. Id say the following "The redo command restarts the loop block without evaluating the conditional says that the following should be functionally identical: while (EXPR) { while (EXPR) { But if EXPR is "my $foo=func()" there is no way to lie to themselves about Yves |
From @smpeters
OK, I've merged together all the related tickets for this problem. This |
From @mjdominusI'm not sure which bug report of mine you are referring to. The only If so, I don't think it should be grouped with this one. It may stem |
From @smpetersOn Mon, Apr 25, 2005 at 10:05:16PM -0400, Mark Jason Dominus wrote:
Mark, Your ticket was titled "redo' destroys value of lexical loop variable" with use strict; This emits the following output: x is 1 |
From @demerphqOn 26 Apr 2005 01:46:02 -0000, Steve Peters via RT
This is definately a bug. The docs are pretty clear that redo should IE: { should be the functionally equivelent to { which i think makes it pretty clear that the redo causing the lexical There is also the following line from perlsyn: "The redo command restarts the loop block without evaluating the Having the variable set to undef completely blows the ability of the Cheers, -- |
From @iabynOn Tue, Apr 26, 2005 at 01:46:02AM -0000, Steve Peters via RT wrote:
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 Dave. -- |
From perl5-porters@ton.iguana.beIn article <20050507133207.GI4731@iabyn.com>,
wouldn't that notably slow down relatively common while(my $process = shift @array) { ? |
From @iabynOn Sat, May 07, 2005 at 03:33:54PM +0000, Ton Hospel wrote:
A little bit. Less than than adding a bare block to the loop. -- |
@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$
The text was updated successfully, but these errors were encountered: