Date: Mon, 1 Jul 1996 11:39:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fenner@parc.xerox.com (Bill Fenner) Cc: bde@zeta.org.au, current@freebsd.org, terry@lambert.org Subject: Re: Problem Report docs/731 Message-ID: <199607011839.LAA06101@phaeton.artisoft.com> In-Reply-To: <96Jul1.081258pdt.177476@crevenia.parc.xerox.com> from "Bill Fenner" at Jul 1, 96 08:12:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607011839.LAA06101>