in reply to Strange modification of @_

$_[0] is aliased to $1. Clearing $1 will therefore clear $_[0], being the same variable. Don't pass globals to functions if that global is going to be modified in the function.

Fix:

s/(x)/fn "$1"/e;

This causes a new string to be created from the value of $1.

Update: Note that this isn't usually a problem with Pure Perl subs since @_ is usually only used at the top of the sub.

Replies are listed 'Best First'.
Re^2: Strange modification of @_
by jrw (Monk) on Apr 23, 2009 at 19:57 UTC
    Yes, that's it -- don't know why I couldn't see it. However, aarrgghh, I don't see an obvious fix for this that doesn't rely on fn() knowing how it's called or the caller (in the outer substitution) knowing how fn() is going to use its argument list. It seems very unnatural to write s/(x)/fn "$1"/e (with quotes around the argument) and it seems equally unnatural to write the body of fn() any differently (by making a copy of $_[0] before performing the substitution. In general, I certainly don't expect that the argument list to a function will be changed merely by doing something as innocuous as performing substitution on a local string.

    I virtually never use fn("$var") instead of fn($var), but I guess if var is a global, including $1, $2, etc, then the safest thing to do is wrap it in quotes to copy the value.

      it seems equally unnatural to write the body of fn() any differently (by making a copy of $_[0] before performing the substitution.

      What are you talking about? Using one of my ($str) = @_; or my $str = shift; is standard practice, hardly unnatural.

      If the issue is that you want both the original and the transformed string, you might also be interested in the following idiom:

      sub fn { my ($old) = @_; (my $new = $old) =~ s/.../.../; ... }
        I meant that both of the potential fixes for this feel unnatural:
        1. using s/(x)/fn "$1"/e (with quotes around $1), or
        2. using what you suggested: (my $new = $old)... or any other form of that.
        Both fixes require an extraordinary amount of coupling between the caller and the function. Either:
        1. the caller needs to know that the argument to fn() will be used directly from @_ after a regexp, or
        2. the function needs to know that the argument is an alias of a global variable which will be modified by the regexp.
        Only if they have this tight coupling does it make sense to use either of these two precautions to avoid the issue I ran into.

        I think the takeaway for me is that when passing $1, etc into a function, that it should be quoted (to copy it), even though the general rule is when passing a variable $var into a function, (almost) never should it be quoted, as in fn("$var"). This feels exactly like the kind of kludgy rules you have to remember to use C++ "correctly".