On Wed, Jul 30, 2008 at 10:12:43AM -0700, H. Peter Anvin wrote:
> Karel Zak wrote:
>> On Wed, Jul 30, 2008 at 03:55:13PM +0200, maximilian attems wrote:
>>> s/signal/bsd_signal/ to make it evident which semantics
>>> are expected.
>>
>> (guy, be happy that Ulrich Drepper is not around:-)
>>
>> why not sigaction(2) ?
>>
>> man bsd_signal:
>> On modern Linux systems, bsd_signal() and signal(2)
>> are equivalent.
>>
>> Do you mean that klibc signal() is different from glibc?
>>
>
> I dropped signal() from klibc entirely, because I didn't like the
> ambiguity between SysV and BSD semantics. "On modern Linux systems"
> refer to the unilateral decision of glibc to switch from signal()
> meaning sysv_signal() to signal() meaning bsd_signal().
>
> This *did* turn out to be a reasonable thing to do, as most code out
> there that uses unadorned signal() appears to be BSD-derived.
>
> I specifically stated in the README for klibc that "if you want signal,
> compile with -Dsignal=bsd_signal or -Dsignal=sysv_signal".
hmm.. fortunately I see sigaction() in klibc code.
> time bomb to have lying around, and that bsd_signal() [which *IS* in
> POSIX!] is a better choice, alternatively the following function:
IEEE P1003.1 Draft 4, 11 January 2008:
B.3.1 System Interfaces Removed in this Version
^^^^^^^^^^^^^^^^^^^^^^
B.3.1.3 bsd_signal
Applications are recommended to use the sigaction( ) function
instead of this function.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
