Xref: utzoo comp.unix.wizards:9579 comp.sys.ibm.pc:16646 comp.lang.c:10871
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!decvax!eagle_snax!geoff
From: geoff@eagle_snax.UUCP ( R.H. coast near the top)
Newsgroups: comp.unix.wizards,comp.sys.ibm.pc,comp.lang.c
Subject: Re: SVVS (was OSF discussion)
Summary: portability to DOS
Message-ID: <312@eagle_snax.UUCP>
Date: 23 Jun 88 12:11:48 GMT
References: <637@spectrix.UUCP> <11410001@eecs.nwu.edu> <595@root44.co.uk>
Lines: 26

In article <595@root44.co.uk>, aegl@root.co.uk (Tony Luck) writes:
> 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?

Being interested in the portability of Un*x applications
to other OS environments (including MS-DOS) I decided to try
this little test program on a few compilers. SunOS gave EBADF.
Microsoft C 4.0 under DOS also gave EBADF. Turbo C under DOS
left errno as 0.....


-- 
Geoff Arnold, Sun Microsystems     | "...And is the Tao in the DOS for a
TOPS at ECD (home of PC-NFS)       | personal computer?" The master coughed and
UUCP:{ihnp4,decwrl...}!sun!garnold | shifted his position slightly. "The
ARPA:garnold@sun.com               | lesson is over for today," he said.