home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk)
-
- In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("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!
-
- The exception that caused the signal has an effect on the process. The
- signal that it causes has no effect (because it is being ignored). The
- behavior of the process is then undefined by the standard because it
- is whatever results from the exception.
-
- > Why not
- > simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
- > is done for SIGKILL and SIGSTOP?
-
- Because that was/is not existing practice. On some specific
- implementation the results of ignoring some exception may be predictable
- and even useful (eg. simply continuing to execute the instruction that
- follows an attempted division by zero). There is no reason for the
- standard to dictate that a non-portable application not be able to
- take advantage of this.
-
- Bob Lenk
- rml@fc.hp.com
- {uunet,hplabs}!fc.hp.com!rml
-
-
- Volume-Number: Volume 27, Number 24
-
-