Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Spot the bug!

by tlm (Prior)
on Oct 26, 2006 at 13:18 UTC ( #580755=note: print w/replies, xml ) Need Help??

in reply to Spot the bug!

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

Replies are listed 'Best First'.
Re^2: Spot the bug!
by diotalevi (Canon) on Oct 26, 2006 at 15:18 UTC

    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

        I said local $@, not @_. There's no point to localizing @_, that's your input! You'd copy stuff out of it if you needed that behavior.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://580755]
and the web crawler heard nothing...

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