in reply to Re^2: Setting signal handlers considered unsafe?
in thread Setting signal handlers considered unsafe?
I'm pleased to see that you have reported this as a bug:
If perl were new, I might argue that local should not set variables when localizing (to undef or anything else and regardless of whether there is an initializer), as initializers are available to set the value and including this feature in local precludes not changing the value. But perl is not new and changing local now would no doubt be problematic.
After reading the further posts in this thread, I am inclined to the view that the design of local is less than ideal but that the only bug is in the documentation. In which case I guess I should submit a patch to the docs to go along with my bug report. I am thinking perlsub and perlipc should probably both be changed. Are there other sections that need attention?
Maybe what is needed is a new operator, very much like local except that it does not change the value of the variable. It's description in perlsub would be exactly as for local except for the definition of what happens if there is no initializer, which might read as follows for the new operator:
If no initializer is given for a particular variable its value is not changed if it already exists or, if it does not already exist, its value is set to undef.
This would leave local as is, so no existing scripts would be broken, and it would provide a new means of managing signal handlers, and anything else where setting the variable to undef, even briefly, is undesirable.
But this wouldn't be a bug, this would be a feature request.
Update: just as I was about to submit patches to perlsub and perlipc, I received notice that a patch has been applied that skips setting undef if there is an initializer. I hope it doesn't upset anyone and get taken out.
>> >> When setting a localized signal handler, the system signal handl +er >> >> is set to SIG_DFL then back to perl's signal handler. This brief +ly >> >> exposes SIG_DFL when switching between alternate non-default sig +nal >> >> handlers. > > > > The below patch fixes this bug. In the process it also partially +fixes a > > magic bug of long standing (probably since 5.000). > > > > When localizing a magical scalar for assignment, Perl has until no +w done an > > extra store of undef before storing the actual desired value. To > > illustrate, given this source code: > > > > { package Foo; > > sub TIEHASH { bless {}, 'Foo' } > > sub FETCH { print "Fetch $_[1]\n"; $_[0]->{$_[1]} } > > sub STORE { print "Store $_[1] = $_[2]\n"; $_[0]->{$_[1]} = +$_[2] } > > } > > > > tie %x, 'Foo'; > > $x{plugh} = "dick"; > > { local $x{plugh} = "jane" } > > > > Released perls and blead do this: > > > > $ perl foo > > Store plugh = dick > > Fetch plugh > > Store plugh = > > Store plugh = jane > > Store plugh = dick > > > > Whereas blead with the below patch does this: > > > > $ ./perl foo > > Store plugh = dick > > Fetch plugh > > Store plugh = jane > > Store plugh = dick > > > > The below patch fixes this problem for hash elements and slices. +However, > > due to the OPf_SPECIAL flag not meaning the same thing in the AELE +M opcodes, > > let alone all the opcodes that can extract scalar values, this fix + is not > > entirely applicable to those cases; that will require deeper hacki +ng. At > > least this patch fixes hashes, which are the most common case. Great fix! Thanks, applied as #34819, except the perlapi.c part, which strips off a Tolkien quote. I'll fix that separately.
|
|---|