This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/749] sigaction() and signal() misbehave


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]