From owner-freebsd-current  Mon Jul  1 11:40:30 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA22789
          for current-outgoing; Mon, 1 Jul 1996 11:40:30 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA22775
          for <current@freebsd.org>; Mon, 1 Jul 1996 11:40:24 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06101; Mon, 1 Jul 1996 11:39:11 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199607011839.LAA06101@phaeton.artisoft.com>
Subject: Re: Problem Report docs/731
To: fenner@parc.xerox.com (Bill Fenner)
Date: Mon, 1 Jul 1996 11:39:11 -0700 (MST)
Cc: bde@zeta.org.au, current@freebsd.org, terry@lambert.org
In-Reply-To: <96Jul1.081258pdt.177476@crevenia.parc.xerox.com> from "Bill Fenner" at Jul 1, 96 08:12:51 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> In message <199606290759.RAA29925@godzilla.zeta.org.au> you write:
> >2a) Investigate possible breakage of socketpair() in foreign libraries
> >    (BSDI, Linux, etc).  Any library that uses the previously suggested
> >    fix of handling socketpair() like pipe() will break.
> 
> NetBSD doesn't touch retval at all (e.g. they simply deleted the two
> XXX lines), like many system calls.  Terry's suggestion of setting it
> to 0 obviously does no harm but is kind of belt-n-suspenders.  Thus
> fixing it in libc will likely break NetBSD compatibility.

I set it to 0 for two reasons:

1)	Other system calls explicitly set zero.  There is an
	implied consistency promise that we aren't keeping.

2)	I suspect that multiple process exit from system space
	and async versions-of/interfaces-to standard system
	calls may in fact lose context without explicit returns.

3)	Implicit error returns bug the hell out of me unless they
	are well documented.  None of the kernel entry points
	are documented, at least not in the comments in the code.
	This is the same argument I had about single-entry/single-exit
	with regard to vfs_syscalls.c: documenting behaviour in a
	readable fashion never hurts.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.