std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/13/85)
Date: Mon, 11 Nov 85 11:53:25 EST From: Dan Franklin <dan@BBN-PROPHET.ARPA> Re EFAULT from time(), etc.: The System V Interface Definition says (p. 136) that "time will fail and its actions are undefined if tloc points to an invalid address" as opposed to other system calls where the SVID explicitly says they will return EFAULT. So it seems that it would not be deviating too much from AT&T's Unix line to permit some system calls to get SIGSEGV given an invalid pointer. It certainly seems the most sensible course to me. I suspect that the discrepancy between the SVID and the SVr2 manual occurs because the SVr2 code doesn't implement what the SVr2 manual says, and the SVID makes SVr2's behavior legitimate. Re limits: it really is much more sensible to determine the limits in a way which permits a vendor to supply them at run time rather than compile time. While I don't want to get into an argument over whether the standard ought to address binary compatibility or not, it seems to me that it should certainly not PRECLUDE a vendor from offering binary compatibility across changes in some system "constants". OPEN_MAX is a particularly good example of a "constant" that is likely to change over the next few years; I know of several database-producing groups that can't stand the limit of 20 open descriptors, and it's not particularly wonderful for the project I'm on now, either. It is true that this will mean that (e.g.) an array of flags will have to be allocated dynamically rather than statically if it is to be done correctly; I don't see this as a serious disadvantage. Dan Franklin Volume-Number: Volume 3, Number 16