home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan")
-
- In article <1992Feb22.232957.16129@uunet.uu.net>,
- karish@mindcraft.com (Chuck Karish) writes:
-
- >SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
- >POSIX.1 that correspond to computational exceptions. Elsewhere
- >in POSIX.1 it is stated that the implementation may generate
- >other, implementation-defined signals. The names of these
- >signals and the conditions under which they are generated
- >are to be documented in the POSIX conformance document.
- >
- >POSIX.1 tries not to keep the implementation from providing
- >additional signals or errno values that give more information
- >to the programmer, as long as the base behavior specified
- >by the Standard is also supported and the appropriate
- >documentation is provided.
-
- I had no question regarding additional implementation defined signals.
- My question was whether an implementation could choose to designate one
- of the other Posix defined signals as "computational" with regards to
- the undefined behaviour when returning from a handler? I think the
- answer is no.
-
- 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 behavior of the process is undefined after a SIGFPE, SIGILL, or
- SIGSEGV signal is delivered, otherwise delivery of the signal shall
- have no effect on the process.
-
- Mike Wulkan
-
-
- Volume-Number: Volume 27, Number 15
-
-