home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v3 / text0015.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  1.6 KB
  1. Date:     Mon, 11 Nov 85 11:53:25 EST
  2. From: Dan Franklin <dan@BBN-PROPHET.ARPA>
  3.  
  4. Re EFAULT from time(), etc.: The System V Interface Definition says (p. 136)
  5. that "time will fail and its actions are undefined if tloc points to an
  6. invalid address" as opposed to other system calls where the SVID explicitly
  7. says they will return EFAULT.  So it seems that it would not be deviating too
  8. much from AT&T's Unix line to permit some system calls to get SIGSEGV given
  9. an invalid pointer.  It certainly seems the most sensible course to me.
  10.  
  11. I suspect that the discrepancy between the SVID and the SVr2 manual occurs
  12. because the SVr2 code doesn't implement what the SVr2 manual says, and the
  13. SVID makes SVr2's behavior legitimate.
  14.  
  15. Re limits: it really is much more sensible to determine the limits in a way
  16. which permits a vendor to supply them at run time rather than compile time.
  17. While I don't want to get into an argument over whether the standard ought to
  18. address binary compatibility or not, it seems to me that it should certainly
  19. not PRECLUDE a vendor from offering binary compatibility across changes in
  20. some system "constants".  OPEN_MAX is a particularly good example of a
  21. "constant" that is likely to change over the next few years; I know of several
  22. database-producing groups that can't stand the limit of 20 open descriptors,
  23. and it's not particularly wonderful for the project I'm on now, either.
  24. It is true that this will mean that (e.g.) an array of flags will have to be
  25. allocated dynamically rather than statically if it is to be done correctly;
  26. I don't see this as a serious disadvantage.
  27.  
  28.     Dan Franklin
  29.  
  30. Volume-Number: Volume 3, Number 16
  31.  
  32.