develooper Front page | perl.perl5.porters | Postings from August 2010

Re: [perl #76138] perl inadvertently destroys signal handlers as of f746176000

Thread Next
From:
Father Chrysostomos
Date:
August 1, 2010 12:09
Subject:
Re: [perl #76138] perl inadvertently destroys signal handlers as of f746176000
Message ID:
512C9E16-2A98-4932-9E89-E482956E6212@cpan.org
This script should make the bug abundantly clear:

@a'SIG{<INT HUB>} = <another Not>;
@b'SIG{<TERM AMP KILL>} = <hacker Yes, Perl>;
@ != qw \! ? \; $ \= "\n";
for$%(a,b){print join(q q q,map ${"$%::SIG"}{$_}
=~/([^R:]{2,})\z/,sort keys%{"$%::SIG"}),pop@!}

Perl_gv_fetchpvn_flags is the culprit. It doesn’t take the package name into account when attaching magic to variables based on their names.

When *SIG is created, undef is assigned to all the elements of %SIG that correspond to signals, so that keys %SIG will work. That’s why the signal handlers are wiped.

Now, if we turn on the magic for %SIG, $!, etc. only when they are in the main package, how much code would break? There are several dozen variables like this. Yet I don’t think anyone is seriously using

 open FH, $file or die ${"'Oh no'!"}

But you never know.... :-)

I could fix this either by making the %SIG initialisation less destructive (have it check whether each elem exists before assigning undef). Or I could stop all this magic from leaking into packages other than main (except for %OVERLOAD, etc.), breaking the JAPH above. Which is preferable?





Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About