This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/749] sigaction() and signal() misbehave
- From: "roland at gnu dot org" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 17 Feb 2005 23:33:59 -0000
- Subject: [Bug libc/749] sigaction() and signal() misbehave
- References: <20050217145236.749.sebastien.decugis@ext.bull.net>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From roland at gnu dot org 2005-02-17 23:33 -------
POSIX says that it's implementation-defined whether delivery of a signal whose
handler was set with `signal' has the effect of signal(signo, SIG_DFL) before
running the handler, or not. Resetting the handler is the traditional SYSV
behavior of `signal', and not resetting it is the traditional BSD behavior.
In glibc, you get the SYSV style when you use some feature macros like
_POSIX_C_SOURCE, but don't also use _BSD_SOURCE or _GNU_SOURCE. If you use
_GNU_SOURCE or you do not define any _*_SOURCE macros at all, then you will get
the BSD behavior. The function `bsd_signal' is available if you use
_XOPEN_SOURCE or _GNU_SOURCE; this is the `signal' that does not reset the
handler, which `signal' gets you under _GNU_SOURCE. Since your test program
defines _POSIX_C_SOURCE, it gets the sysv_signal flavor instead. The only way
to be POSIX-compliant here is not to rely on `signal' one way or the other, and
instead stick to using `sigaction'.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://sources.redhat.com/bugzilla/show_bug.cgi?id=749
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.