home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0008.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.8 KB
  1. Date: 06 Oct 85 18:54:15 +1000 (Sun)
  2. >From: Robert Elz <munnari!kre@seismo.CSS.GOV>
  3.  
  4. I notice that P1003 has gone to a lot of trouble (I refer to draft 4)
  5. to specift that EFAULT is a possible error return from every system
  6. call that takes a pointer as one of its arguments (or if there are
  7. any that were missed, I missed them too!)
  8.  
  9. I have yet to see an implementation that will actually return EFAULT
  10. in many of those instances - consider "time()", "wait()", and "pipe()".
  11.  
  12. [ System V Release 2 claims to return EFAULT in most of these
  13. cases, including time() and wait().  (I don't know if it really
  14. does.)  Clearly this is what one would want to have happen.
  15. If a signal occurred instead, and the user signal catcher
  16. returned normally, how would one then complete the system
  17. call?  Surely not by returning EINTR :-)  -Gwyn ]
  18.  
  19. In each of those, the system call definition specifies that a pointer
  20. to a data structure of one type or another is an argument.  However,
  21. all implementatins that I am aware of do not actually pass the pointer
  22. across the user/kernel interface, preferring rather the obtain the
  23. returned value via some system defined internal mechanism, and have the
  24. user interface routine actually store it in the data structure the
  25. user intended.
  26.  
  27. If such an implementation is required to return EFAULT rather than
  28. send a signal to the process, much extra work is going to be involved.
  29. Since (probably) all implementations are involved here, it seems to
  30. me that things should be relaxed here.
  31.  
  32. [ Agreed.  -Kretsch ]
  33.  
  34. [ Isn't u.u_error available for the copyout() code?  Setting it
  35. to EFAULT instead of posting a signal seems a trivial change.  -Gwyn ]
  36.  
  37. I would add the following sentence to the definition of EFAULT in
  38. section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ]:
  39.  
  40.     This condition may generate a signal; the error is returned
  41.     if the signal is not generated, or is ignored.
  42.  
  43. [ I'm not sure this is the proper action.  This may cause currently
  44. working programs to break.  -Kretsch ]
  45.  
  46. This closely follows the wording of the similar condition with EPIPE,
  47. except that it allows implementations to decide in which cases they
  48. will send a signal, and in which cases they will return EFAULT.
  49.  
  50. [ This may turn out to be a good compromise solution.  -Gwyn ]
  51.  
  52. I would actually prefer if new kernel implementations could dispense
  53. with EFAULT entirely, and send a SIGSEGV instead (returning EFAULT
  54. only if the signal is ignored).
  55.  
  56. This would greatly help to blur the distinction between what is
  57. a "system call" and what is a "library routine".
  58.  
  59. It seems to me, that now the time has come when most of us no longer
  60. write code in assembler, this distinction is outdated.  To me,
  61. a "system call" and a "library routine" look just the same.
  62.  
  63. If the kernel sent a signal whenever it detected an illegal address
  64. in an argument provided by a user to a system call, then system
  65. calls would behave just like library routines, and it would be
  66. much easier for an implementation to choose how to implement
  67. any particular function.  For example, on some systems, it may
  68. be desirable to implement "uname()" as a library routine that reads
  69. a file - to allow the data returned to be easily changed by
  70. the site administrators.  This is not going to be easy to do
  71. if uname() is constrained to return EFAULT and not send a SIGSEGV.
  72.  
  73. [ Indeed, one of the silliest parts of emulating system calls
  74. with library routines (as in my System V emulation for 4.2BSD)
  75. is the attempt to return EFAULT instead of causing a SIGSEGV.
  76.  
  77. What you say is quite right, but it would be a significant change
  78. from the System V baseline so I suspect we would not arrive at a
  79. consensus in favor of the SIGSEGV approach.
  80.  
  81. Draft 5 Appendix A.7 specifically mentions problems with EFAULT
  82. and solicits suggestions for incorporation into the "final use"
  83. standard.  -Gwyn ]
  84.  
  85. Robert Elz        seismo!munnari!kre   kre%munnari.oz@seismo.css.gov
  86.  
  87. Volume-Number: Volume 3, Number 9
  88.  
  89.