home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0018.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  1.6 KB  |  51 lines
  1. Submitted-by: karish@mindcraft.com (Chuck Karish)
  2.  
  3. In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM
  4. ("Mike Wulkan") writes:
  5. >I had no question regarding additional implementation defined signals.
  6. >My question was whether an implementation could choose to designate one
  7. >of the other Posix defined signals as "computational" with regards to
  8. >the undefined behaviour when returning from a handler?  I think the
  9. >answer is no.
  10.  
  11. I agree.
  12.  
  13. >Why would the behavior of a process be UNDEFINED if the signal has NO
  14. >EFFECT on the process?
  15.  
  16. Because the event that caused the signal to be generated
  17. has already corrupted the process's execution environment.
  18.  
  19. >Obviously the signal has an effect!
  20.  
  21. When it's ignored?
  22.  
  23. >Why not
  24. >simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and SIGSEGV as
  25. >is done for SIGKILL and SIGSTOP?
  26.  
  27. Because the process can sometimes exit gracefully.  No
  28. guarantee, though.
  29.  
  30. >At the very least it would seem that
  31. >the section would be more accurately worded:
  32. >
  33. >  The behavior of the process is undefined after a SIGFPE, SIGILL, or
  34. >  SIGSEGV signal is delivered, otherwise delivery of the signal shall
  35. >  have no effect on the process.
  36.  
  37. The behavior of the process is defined after one of these
  38. signals is delivered: abnormal termination.  The second
  39. sentence is unnecessary, because the process of catching a
  40. signal is already well defined.  By re-writing this, you've
  41. removed the warning that the signals in question indicate
  42. that the process is in trouble from which the operating
  43. system can not rescue it.
  44.  
  45.     Chuck Karish        karish@mindcraft.com
  46.     Mindcraft, Inc.        (415) 323-9000
  47.  
  48.  
  49. Volume-Number: Volume 27, Number 20
  50.  
  51.