Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!mandrill!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: SVVS (was OSF discussion) Message-ID: <8187@ncoast.UUCP> Date: 26 Jun 88 16:34:19 GMT References: <637@spectrix.UUCP> <11410001@eecs.nwu.edu> <3c8b1c7c.4bee@apollo.uucp> <55906@sun.uucp> <595@root44.co.uk> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 27 As quoted from <595@root44.co.uk> by aegl@root.co.uk (Tony Luck): +--------------- | calls. SVVS (2.0 maybe 3.0) gives bogus arguments to system calls and | checks that 'errno' is set to the 'correct' value. This can cause problems | if your kernel doesn't check the arguments in the same order that an AT&T | kernel does. E.g. what should be the error caused by this call to read(2)? | | close(0); | read(0, (char *)NULL, -23); | | There are some tests in SVVS 2.0 that require certain error returns even | though more than one seems possible. +--------------- This sounds like a bug in SVVS or an incomplete SVID. Either case should be fixed: either AT&T should define the argument checking in the SVID or they should accept any of the error returns possible from the call. Before you flame AT&T to death about this, remember that they're fairly new to this kind of thing; it'll take some time to work the glitches out of both SVID and SVVS, and the only way it'll get done is if you tell AT&T that the glitches exist and give examples. -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore