home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0015.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  2.2 KB  |  51 lines
  1. Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
  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.  
  8.      "Delivery of the signal shall have no effect on the process.
  9.      The behavior of a process is undefined after it ignores a SIGFPE,
  10.      SIGILL, or SIGSEGV signal ..."
  11.  
  12.    Why would the behavior of a process be UNDEFINED if the signal has NO
  13.    EFFECT on the process?  Obviously the signal has an effect!  Why not
  14.    simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
  15.    is done for SIGKILL and SIGSTOP?  At the very least it would seem that
  16.    the section would be more accurately worded:
  17.  
  18.      The behavior of the process is undefined after a SIGFPE, SIGILL, or
  19.      SIGSEGV signal is delivered, otherwise delivery of the signal shall
  20.      have no effect on the process.
  21.  
  22. It isn't the signal that has the effect.  It's that the machine will
  23. do something odd.  For example, on a Vax, an illegal memory reference
  24. is a fault.  If the generated signal is ignored, the result is an
  25. infinite loop.  It is useful for the OS to specify this.  On the other
  26. hand, it is also useful for Posix to leave it undefined, because
  27. different hardware and different OS's recover from such things
  28. differently.
  29.  
  30. If you just do `kill -ILL 387', and process 387 has set the handler
  31. for SIGILL to SIG_IGN, truly nothing should happen.  I believe Posix
  32. should specify this, but I don't believe it does.
  33.  
  34. The confusion here is between the hardward (implementation-defined)
  35. event causing the signal and the signal itself.
  36.  
  37. Your suggested fix is not adequate, however.  People should be able to
  38. catch illegal references in programs, and then be able to exit nicely.
  39. Your "fix" precludes doing so portably.
  40.  
  41.     -mib
  42. --
  43. Michael Innis Bushnell      | This is a virulent meme.  Whether or not you place
  44. Email: mib@gnu.ai.mit.edu | this into your signature file is irrelevant.  You
  45. Phone: (617) 625-4518      | have already participated in its further trans-
  46.               | mission, and will doubtless continue to do so.
  47.  
  48.  
  49. Volume-Number: Volume 27, Number 17
  50.  
  51.