Closed p5pRT closed 20 years ago
I believe I've discovered a subtle bug relating to local and @_.
Here's my test case:
#!/usr/bin/perl -w use strict;
print_args( 123\, 456\, 789 );
sub print_args { tamper_args( 'All your arguments are belong to us.' ); print "My arguments were: " . join('\, '\, @_) . "\n"; }
sub tamper_args { local @_ = ( 'This is not a potato.' ); }
On my machine (perl v5.6.1 for darwin)\, the call to tamper_args somehow clobbers the argument list visible to print_args\, producing the following startling result: "My arguments were: All your arguments are belong to us."
This appears to be a conflict between the restoration of local values at the end of a sub {...} scope and the restoration of @_ that always happens at the end of a sub. In particular\, the problem goes away if the local is inside another { } block (presumably because the two scope-exits are handled separately). It also goes away if tamper_args is called without a parenthesized argument list (presumably because there's no implicit local-ization in that case.
This issue was posted to PerlMonks.org\, where others reported similar behavior on Perl 5.6.x\, and a different failure condition for Perl 5.005. http://www.perlmonks.org/index.pl?node_id=138370
Now\, I'll grant that there's generally no need to local @_ like this\, but I've also not been able to find anything that says you're not allowed to do so -- seems like a low priority core bug.
-Simon
Confirmed in perl@13811 (which I had lying around)\, so presumably still present in bleadperl.
Would it be reasonable just to forbid localisation of @_? Maybe that's overkill\, since it seems to work in a loop (or block) scope\, just not in an actual subroutine scope.
.robin.
On Tue\, Jan 15\, 2002 at 02:29:49PM +0000\, Robin Houston wrote:
Would it be reasonable just to forbid localisation of @_?
No.
There are function that take @_ as a default argument\, like shift and pop. To forbid localisation of @_ is like forbidding localisation of $_.
Abigail
(Just reviewing old perl bug reports).
This has been fixed in the soon-to-be-released Perl 5.8.1\, Probably by patch #19064
@iabyn - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#8231 (status was 'resolved')
Searchable as RT8231$