Don't local(@_)

[simonm]

An interesting discovery about local has emerged in the course of debugging Class::MakeMethods (thanks to an excellent bug report from Adam Spiers).

Take a moment to predict the output of the code below before you run it.

#!/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.

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 -- perhaps this consitutes an actual Perl bug?

[blakem]

Ouch! That looks like a bug to me... (unless I'm misunderstanding some deep voodoo) BTW 5.00503 and 5.6.1 behave differently on linux (though neither behave as I would expect...):

% perl5.00503 tamper.pl
My arguments were: 

% perl5.6.1 tamper.pl
My arguments were: All your arguments are belong to us.

% perl5.6.0 tamper.pl 
My arguments were: All your arguments are belong to us.

Update: Added 5.6.0 test from a different linux machine...
Update2: You might try playing around with local *_ which doesn't do the right thing, but at least it does something different....

-Blake

[hossman]

This definitely strikes me as a bug. Per Programming Perl...

If you have a local that looks like this:

     {
         local $var = $newvalue;
         some_func();
         ...
     }

you can think of it purely in terms of run-time assignments:

     {
         $oldvalue = $var;
         $var = $newvalue;
         some_func();
         ...
     }
     continue {
         $var = $oldvalue;
     }

The difference is that with local the value is restored no matter how you exit the block, even if you prematurely return from that scope.

Regardless of or what variable you are local'ing in your sub, it should return it to it's orriginal value on exit -- and it certainly shouldn't affect the callers scope.

[robin]

I agree with the previous posters that this is definitely a bug of some sort. Whether it ought to work, I'm less sure: perhaps it should just be forbidden to localise @_.

I tried your test code on a fairly recent development snapshot of perl, and the bug is still there. You should perlbug it. (Run the perlbug command and follow the instructions.)

[dmmiller2k]

Nice catch! Definitely looks like a bug.

Although I'm having trouble envisioning under what circumstances this would create a problem in production code (I don't remember ever having a reason to localize @_), it's still a good catch. .

dmm

If you GIVE a man a fish you feed him for a day
But, TEACH him to fish and you feed him for a lifetime