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