home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0023.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  1.4 KB  |  38 lines

  1. Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk)
  2.  
  3. In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
  4.  
  5. > On a similar note, there seems to be a contradiction in the
  6. > section describing SIG_IGN which reads:
  7. >   "Delivery of the signal shall have no effect on the process.
  8. >   The behavior of a process is undefined after it ignores a SIGFPE,
  9. >   SIGILL, or SIGSEGV signal ..."
  10. > Why would the behavior of a process be UNDEFINED if the signal has NO
  11. > EFFECT on the process?  Obviously the signal has an effect!
  12.  
  13. The exception that caused the signal has an effect on the process.  The
  14. signal that it causes has no effect (because it is being ignored).  The
  15. behavior of the process is then undefined by the standard because it
  16. is whatever results from the exception.
  17.  
  18. >                                                              Why not
  19. > simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
  20. > is done for SIGKILL and SIGSTOP? 
  21.  
  22. Because that was/is not existing practice.  On some specific
  23. implementation the results of ignoring some exception may be predictable
  24. and even useful (eg. simply continuing to execute the instruction that
  25. follows an attempted division by zero).  There is no reason for the
  26. standard to dictate that a non-portable application not be able to
  27. take advantage of this.
  28.  
  29.         Bob Lenk
  30.         rml@fc.hp.com
  31.         {uunet,hplabs}!fc.hp.com!rml
  32.  
  33.  
  34. Volume-Number: Volume 27, Number 24
  35.  
  36.