home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0014.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.8 KB
  1. Date: Sun, 10 Nov 85 16:19:03 PST
  2. From: mordor!lll-crg!sun!guy (Guy Harris)
  3.  
  4. > [ System V Release 2 claims to return EFAULT in most of these
  5. > cases, including time() and wait().  (I don't know if it really
  6. > does.)  Clearly this is what one would want to have happen.
  7. > If a signal occurred instead, and the user signal catcher
  8. > returned normally, how would one then complete the system
  9. > call?  Surely not by returning EINTR :-)  -Gwyn ]
  10.  
  11. Normally, one wouldn't *want* to complete the system call in this case; how
  12. do you complete a call to "time" where the pointer points into some
  13. nonexistent or non-writable location?  The only case where this would be
  14. useful is in something like (aargh) the Bourne shell, where the signal
  15. catcher would grow the data space to make that pointer valid.  This would
  16. only work with 4.xBSD-style restartable system calls; the system call should
  17. *not* be completed, but re-executed.
  18.  
  19. > [ Isn't u.u_error available for the copyout() code?  Setting it
  20. > to EFAULT instead of posting a signal seems a trivial change.  -Gwyn ]
  21.  
  22. "copyout" isn't being used here; the copying of the data from the registers
  23. it's usually returned in (for calls like "wait", "time", and "pipe") into
  24. the location pointed to by the argument to the system call is done by
  25. user-mode code, and it'd have to catch SIGSEGV in order to make the system
  26. call return EFAULT in that particular case (oh yes, and in the cases of
  27. "wait" and "pipe", you couldn't re-execute the call).
  28.  
  29. > I would add the following sentence to the definition of EFAULT in
  30. > section 2.3 [ of Draft 4; Section 2.4 of Draft 5 -jsq ]:
  31.  
  32. >     This condition may generate a signal; the error is returned
  33. >     if the signal is not generated, or is ignored.
  34.  
  35. > [ I'm not sure this is the proper action.  This may cause currently
  36. > working programs to break.  -Kretsch ]
  37.  
  38. 1) The P1003 standard *already* breaks currently working programs; no UNIX
  39. which is currently available returns -1 and sets "errno" to EAGAIN on
  40. no-delay reads or writes - either it returns 0 (S3, S5) or returns -1 and
  41. sets "errno" to EWOULDBLOCK.
  42.  
  43. 2) It's not clear that *reasonable* existing programs would be broken - what
  44. can you do with an EFAULT except print an error message and exit?  Getting a
  45. SIGSEGV would do both of the above, at least with a reasonable parent
  46. process (like a shell), and would have the added advantage of giving you a
  47. core dump so you can debug the problem more easily (if a system call gets
  48. EFAULT, there is buggy code somewhere).
  49.  
  50. > I would actually prefer if new kernel implementations could dispense
  51. > with EFAULT entirely, and send a SIGSEGV instead (returning EFAULT
  52. > only if the signal is ignored).
  53.  
  54. YES.  V6 (!) did this; EFAULT was added subsequent to the release of V6, and
  55. appeared in PWB/UNIX 1.0, V7, and its successors (4.xBSD, S3, S5, ...).  I
  56. am at a loss to figure out why this was done.
  57.  
  58. Volume-Number: Volume 3, Number 15
  59.  
  60.