http://qs321.pair.com?node_id=11119108


in reply to Perl::Critic says don't modify $_ in list functions and other things

Other monks have mentioned this, but not in these words: map, grep, and for/foreach arrange for $_ to be an alias to each element of the list in turn. In a map block, $_ is not its own variable and modifying $_ will reach back into the original list. In some cases, $_ can even be aliased to some value slot that is read-only, and attempting to modify $_ will fail; for this reason, subs using $_ should localize *_, which replaces the entire glob and "shadows" any aliases that have been established in outer contexts.

There are several reasons to avoid eval STRING that do not affect eval BLOCK. An obvious problem is that eval STRING parses Perl code from a string. If that string is untrusted remote user input and not very, very, very strictly checked, you have a remote code execution vulnerability. There is also a performance issue, in that eval STRING must invoke perl's parser each time it is reached at runtime, while the BLOCK in eval BLOCK is compiled along with the rest of the program. This also leads to one of the reasons eval STRING can be needed: because the STRING is not compiled until runtime, eval STRING can also trap compilation errors in STRING, while a compilation error in the BLOCK in eval BLOCK is fatal before execution starts.

Replies are listed 'Best First'.
Re^2: Perl::Critic says don't modify $_ in list functions and other things
by haukex (Archbishop) on Jul 10, 2020 at 19:34 UTC
    subs using $_ should localize *_, which replaces the entire glob

    Since this only about $_, then local $_; is better, because localizing @_ is unlikely to be in the sub's interest. (Update: Except on Perl versions before 5.14, as per the replies.)

      Using local $_ can fail if $_ is currently aliased to something read-only. The "Localization of special variables" and "Localization of globs" sections in perlsub explained this and recommended using local *_ instead in the affected versions. You can avoid problems with also localizing @_ by unpacking your arguments into lexicals before localizing *_.

      Beginning with perl 5.14, local $_ is a special case that also strips any magic associated with $_, while preserving the other slots in *_. Since Lady_Aleena mentions that her Web host is using a perl older than 5.14, this is a concern for our questioner.

        Beginning with perl 5.14, local $_ is a special case

        Ah, I see, you're referring to RT#84774. Thanks for clarifying.

        Update: Since the OP is no longer on 5.8.8, I think it's appropriate to mention that the local *_ workaround is no longer necessary.