Path: utzoo!attcan!uunet!mcvax!ukc!stc!root44!aegl
From: aegl@root.co.uk (Tony Luck)
Newsgroups: comp.unix.wizards
Subject: SVVS (was OSF discussion)
Message-ID: <595@root44.co.uk>
Date: 17 Jun 88 13:39:51 GMT
References: <637@spectrix.UUCP> <11410001@eecs.nwu.edu> <3c8b1c7c.4bee@apollo.uucp> <55906@sun.uucp>
Reply-To: aegl@root44.UUCP (Tony Luck)
Organization: UniSoft Ltd, London, England
Lines: 18

One area in which a system may not pass SVVS if the code is not taken
directly from the gospel according to AT&T is error returns from system
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);

Should you get 'EBADF' because the file descriptor is invalid, or 'EFAULT'
because the buffer pointer is bogus, or 'EINVAL' because the number of
characters to be read is silly?

There are some tests in SVVS 2.0 that require certain error returns even
though more than one seems possible.

-Tony Luck