Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.27/text0021.txt

Text File | 1992-05-20 | 1.7 KB | 42 lines

Submitted-by: [e-mail] (Fred Zlotnick)

In article <[e-mail]> [e-mail] ("Mike Wulkan") writes:
>    [ ... ]
>On a similar note, there seems to be a contradiction in the
>section describing SIG_IGN which reads:
>
>  "Delivery of the signal shall have no effect on the process.
>  The behavior of a process is undefined after it ignores a SIGFPE,
>  SIGILL, or SIGSEGV signal ..."
>
>Why would the behavior of a process be UNDEFINED if the signal has NO
>EFFECT on the process?  Obviously the signal has an effect!  Why not
>simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
>is done for SIGKILL and SIGSTOP?  At the very least it would seem that
>the section would be more accurately worded:
>
The signal has no effect.  The reason the behavior is undefined is that
the process has gotten an arithmetic point exception (SIGFPE) or
has executed an illegal instruction (SIGILL) or has referenced an
address outside its address space (SIGSEGV).  After any of these
exceptions, the behavior of the process is undefined.

Of course these signals can be generated by other means, for example
through kill() or raise().  These are specifically excluded by the
standard:  The sentence quoted above ends

    ...or SIGSEGV signal that was not generated by the kill()
    function or the raise() function defined by the C Standard.

Any other event that generates one of these signals is presumably
(i.e., in a reasonable implementation) another type of exception.
----
Fred Zlotnick            |  "A standard is a treaty between the
[e-mail]        |   customer and the implementor."
...!{uupsi,ames}!mindcrf!fred     |            Henry Spencer
#include <std/disclaimer>    |


Volume-Number: Volume 27, Number 22