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
Behaviour of the SIG handler with weird hook values poorly documented #17180
Labels
Comments
From choroba@matfyz.czCreated by choroba@matfyz.czHi, Some edge case values (e.g. undef, empty string) aren't properly Ch. Perl Info
|
From choroba@matfyz.cz0001-Document-the-SIG-handler-behaviour-for-weird-hook-va.patchFrom 083e34454b5511db7aefa37e066deaeea8153c4e Mon Sep 17 00:00:00 2001
From: "E. Choroba" <choroba@cpan.org>
Date: Fri, 11 Oct 2019 13:59:38 +0200
Subject: [PATCH] Document the SIG handler behaviour for weird hook values
Values like undef or an empty string can be assigned to the SIG hash.
Their behaviour is slightly different for signals and internal hooks
and wasn't properly documented.
---
pod/perlvar.pod | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/pod/perlvar.pod b/pod/perlvar.pod
index 5f48dad7c0..930b823857 100644
--- a/pod/perlvar.pod
+++ b/pod/perlvar.pod
@@ -607,7 +607,8 @@ The hash C<%SIG> contains signal handlers for signals. For example:
Using a value of C<'IGNORE'> usually has the effect of ignoring the
signal, except for the C<CHLD> signal. See L<perlipc> for more about
-this special case.
+this special case. Using an empty string or C<undef> as the value has
+the same effect as C<'DEFAULT'>.
Here are some other examples:
@@ -622,6 +623,11 @@ Here are some other examples:
Be sure not to use a bareword as the name of a signal handler,
lest you inadvertently call it.
+Using a string that doesn't correspond to any existing function or a
+glob that doesn't contain a code slot is equivalent to C<'IGNORE'>,
+but a warning is emitted when the handler is being called (the warning
+is not emitted for the internal hooks described below).
+
If your system has the C<sigaction()> function then signal handlers
are installed using it. This means you get reliable signal handling.
@@ -640,8 +646,9 @@ errors, like this:
local $SIG{__WARN__} = sub { die $_[0] };
eval $proggie;
-As the C<'IGNORE'> hook is not supported by C<__WARN__>, you can
-disable warnings using the empty subroutine:
+As the C<'IGNORE'> hook is not supported by C<__WARN__>, its effect is
+the same as using C<'DEFAULT'>. You can disable warnings using the
+empty subroutine:
local $SIG{__WARN__} = sub {};
@@ -661,6 +668,9 @@ at a distance like rewriting a pending exception in C<$@>. Plans to
rectify this have been scrapped, as users found that rewriting a
pending exception is actually a useful feature, and not a bug.
+The C<$SIG{__DIE__}> doesn't support C<'IGNORE'>, it has the same
+effect as C<'DEFAULT'>.
+
C<__DIE__>/C<__WARN__> handlers are very special in one respect: they
may be called to report (probable) errors found by the parser. In such
a case the parser may be in inconsistent state, so any attempt to
--
2.16.4
|
Corion
pushed a commit
that referenced
this issue
Oct 21, 2019
Values like undef or an empty string can be assigned to the SIG hash. Their behaviour is slightly different for signals and internal hooks and wasn't properly documented. ### From choroba@matfyz.cz #### Created by choroba@matfyz.cz Hi, Some edge case values (e.g. undef, empty string) aren't properly documented for the %SIG handler. Patch attached. Ch. Autocreated from #17180
Corion
pushed a commit
that referenced
this issue
Oct 25, 2019
Values like undef or an empty string can be assigned to the SIG hash. Their behaviour is slightly different for signals and internal hooks and wasn't properly documented. ### From choroba@matfyz.cz #### Created by choroba@matfyz.cz Hi, Some edge case values (e.g. undef, empty string) aren't properly documented for the %SIG handler. Patch attached. Ch. Autocreated from #17180
Thank you for the patch! It's applied as 40719f1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Migrated from rt.perl.org#134493 (status was 'new')
Searchable as RT134493$
The text was updated successfully, but these errors were encountered: