New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assigning number to %SIG should fail #12867
Comments
From @epaCreated by @epaThe %SIG hash lets you store a code ref, the magic keywords 'DEFAULT' or 'IGNORE', or another string. However, you can store strings such as '1' which are not legal subroutine names $SIG{__WARN__} = 1; # should fail somehow This would be useful because it would catch the mistake of putting code instead of an anonymous sub: $SIG{__WARN__} = say 'something went wrong'; With this proposed change, the return value of say() being 0 or 1 would not be I might also suggest that 'use strict' should disable storing the names of subroutines Perl Info
|
From zefram@fysh.orgEd Avis wrote:
Not very special, since "1" does actually meet Perl's identifier syntax *1 = sub { print "hi"; }; A better example would be "!a", the use of which requires braces and *{"!a"} = sub { print "hi"; }; Hmm, still not terribly special lengths. Haven't had to touch the
No, they work: $ perl -lwe '*1 = sub { print "hi"; }; $SIG{INT} = 1; kill "INT", 0' If you don't define the sub, the fault is reported (as a warning) when $ perl -lwe '$SIG{INT} = "foo"; print "x"; kill "INT", 0; print "y"' This substitute handler could sensibly die rather than warn.
Currently the behaviour of a string (other than the magic strings)
It would only catch it if the code evaluates to something that doesn't Also, how often do you make this mistake? Once per person is probably
Such a stricture makes some sense, but not under "use strict" and, Maybe you want to wrap up assignment to %SIG in a subroutine that checks -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From @epaBy 'code that goes to special lengths to mess with the symbol table'
Ah, the case I tested was this: $ perl -E '$SIG{__WARN__} = "1"; warn' I had expected to get an error 'undefined subroutine main::1 called' % perl -E 'use warnings; $SIG{__WARN__} = "a"; warn' So that's a separate issue: nonexistent subroutine names should fail,
What you wrote is true for $SIG{INT} but appears not so for __WARN__
I don't suggest that. I think there should be a warning at the point
Pretty often if my own limited record is to be taken as representative ;-p. I think that a check on assignment to $SIG{x} (that the value is not a string -- ______________________________________________________________________ |
From zefram@fysh.orgEd Avis wrote:
I'd rather not tie together these disparate aspects of Perl programming.
Aha, this is indeed a problem. If $SIG{__WARN__} or $SIG{__DIE__} is a -zefram |
From @epaI don't mean to cast any judgements on typeglob assignment or anything like that. A warning would indeed have a false positive if someone really wanted to make -- ______________________________________________________________________ |
Migrated from rt.perl.org#117261 (status was 'open')
Searchable as RT117261$
The text was updated successfully, but these errors were encountered: