Re: 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

Comment on Re: Spot the bug! Select or Download Code

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; }` [download] ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply] [d/l] [select]
Re^3: Spot the bug! by tlm (Prior) on Oct 27, 2006 at 00:49 UTC
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	[reply] [d/l] [select]
Re^4: Spot the bug! by diotalevi (Canon) on Oct 27, 2006 at 05:09 UTC
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. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply] [d/l]


more useful options
	PerlMonks