I agree. The docs are misleading.
OK, so we're agreed: either the code doesn't do what the documentation says, or vice versa -- a bug in one or the other, by any reasonable standard, IMO :-)
Not so. I rely on that feature all the time.
Now I'm fascinated. I confess, I've tried, but I cannot imagine a useful purpose for the fact that local $foo = 76 ; fleetingly sets $foo to undef, before setting it to the required 76.
I understand that local $fred ; sets $fred to undef. As far as I can see your code fragment:
performs a local $fred (setting it undef) and passes that to sub d where it, eventually gets treated/returned as an lvalue. So far, so interesting. I only wish I could see how that informs the simpler case of:
where there is a straightforward initialiser and, AFAICS, no urgent need to set $fred to undef immediately before setting it to 'ho hum'.our $fred = 78 ; local $fred = 'ho hum' ;
Remembering, that the point here is that the current behaviour means that the recommended use of local for $SIG creates a very nasty hiatus in which the SIG_DFL state is set.
One can, of course, ignore the standard advice and save and restore the $SIG state by hand. Or get out POSIX and block the signal during the local. This second turns out to be essential in order to use local to automatically restore the $SIG state on forced exit (die) from an eval.
In reply to Re^6: Setting signal handlers considered unsafe?
by gone2015
in thread Setting signal handlers considered unsafe?
by gnosek
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |