home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0019.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  2.0 KB  |  45 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <1992Feb26.202432.17940@uunet.uu.net> WULKAN@TOROLAB6.VNET.IBM.COM ("Mike Wulkan") writes:
  4. >On a similar note, there seems to be a contradiction in the
  5. >section describing SIG_IGN which reads:
  6. >  "Delivery of the signal shall have no effect on the process.
  7. >  The behavior of a process is undefined after it ignores a SIGFPE,
  8. >  SIGILL, or SIGSEGV signal ..."
  9. >Why would the behavior of a process be UNDEFINED if the signal has NO
  10. >EFFECT on the process?  Obviously the signal has an effect!
  11.  
  12. The first sentence states the general rule; the second then modifies it
  13. with particular exceptions.  That in fact reflects the way the signal
  14. mechanism evolved and the way that we think about it.
  15.  
  16. >Why not simply disallow SIG_IGN to be specified for SIGFPE, SIGILL and
  17. >SIGSEGV as is done for SIGKILL and SIGSTOP?
  18.  
  19. The effect as worded is to render such programs not maximally portable
  20. anyway.  (In Standard C parlance they would be "not strictly conforming".)
  21.  
  22. In the course of preparing such standards, often there was political
  23. pressure to "not disallow" certain examples of existing programming
  24. practice.  Whenever the standard really could not promise semantics
  25. for such constructs, there was the choice of forbidding them (and in
  26. the case of the C language standard, requiring a diagnostic) or
  27. allowing them with caveats about their non-portability.  Often the
  28. latter was more acceptable to the standards group than the former.
  29. I no longer recall why our signals working subgroup ended up with the
  30. exact wording you cited, but my guess is it was partly practical
  31. politics aimed at arriving at a consensus.
  32.  
  33. >At the very least it would seem that
  34. >the section would be more accurately worded:
  35. >  The behavior of the process is undefined after a SIGFPE, SIGILL, or
  36. >  SIGSEGV signal is delivered, otherwise delivery of the signal shall
  37. >  have no effect on the process.
  38.  
  39. The time to make such comments is during the public review of the
  40. proposed standard.  You missed that by several years.
  41.  
  42.  
  43. Volume-Number: Volume 27, Number 18
  44.  
  45.