Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Spot the bug!

by tlm (Prior)
on Oct 25, 2006 at 21:03 UTC ( #580652=perlmeditation: print w/replies, xml ) Need Help??

Just got my butt chomped by this one, so I thought I'd share.

What's wrong with this function?

sub foo { return eval { bar( shift ) } || 0; }
The answer does not depend on the definition of bar. E.g. let bar be
sub bar { return shift; }

the lowliest monk

Replies are listed 'Best First'.
Re: Spot the bug!
by ikegami (Pope) on Oct 25, 2006 at 21:13 UTC
Re: Spot the bug!
by Errto (Vicar) on Oct 25, 2006 at 23:00 UTC
Re: Spot the bug!
by Anonymous Monk on Oct 26, 2006 at 07:13 UTC
    Red herrings, and a wrong conclusion. It has nothing to do with either @_, or eval. It all has to do with Perl using pass by alias.
    #!/usr/bin/perl use strict; use warnings; my $n; sub foo { $n = 0; return $_[0]; } print foo(3), "\n"; $n = 3; print foo($n), "\n"; __END__ 3 0
    $_[0] is just a different name for $n, which is being modified in foo, just like your function uses eval, which sets $@.
Re: Spot the bug!
by tlm (Prior) on Oct 26, 2006 at 13:18 UTC

    Actually, after thinking about it some more, I think that the argument below (which I generally agree with in the abstract), does not apply to the example I posted, because, as the repliers pointed out in the first place, avoiding @_ inside an eval won't prevent $@ from being clobbered by the eval. To follow the prescription I proposed below would require localizing the eval within the function... I'm coming around to my detractors' point of view. I stand corrected.

    It was interesting to read the replies, if nothing else just to see how perspectives on something like this can differ. Maybe this is one of those "six tomaytoes/half-a-dozen tomahtos"-type arguments...

    The example I posted illustrates a collision of expectations: the function caller's, which is that "any reasonable, well-behaved function" won't modify the arguments passed to it; and the function writer's, which is that "any reasonable, halfway-intelligent programmer" won't pass as argument to a function anything that shouldn't modified. Clearly one (at least) of these two expectations needs to be corrected. Take your pick.

    In my humble opinion it's the function caller's expectation above that seems the most reasonable of the two, and therefore I proposed what amounts to an adjustment in the function writer's expectations, but all the repliers to my post think it is exactly the other way around. Verrry interesting...

    Of course, one could argue that the best (i.e. most defensive) practice would be to change both expectations...

    the lowliest monk

      Localizing $@ would have protected your caller against your clobbering $@. You'd still have the alias/copy bug so now shift() would always return undef because $@ now is always blank but at least you'd be safer. When using $@, always, always, always copy it out first. The smallest piece of code can go clobber $@ so you should always copy it out before examining it.

      sub foo { local $@; return eval { bar( shift ) } || 0; }

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

        Agreed. But what about just using @_ = @_ instead of local @_? Assignment to @_ is what the docs prescribe for breaking the aliasing. Any reason for preferring one approach over the other?

        the lowliest monk

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://580652]
Approved by jdporter
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2021-01-25 08:05 GMT
Find Nodes?
    Voting Booth?