[comp.unix.wizards] Passing 0 to accept

ag@cbmvax.UUCP (Keith Gabryelski) (09/18/89)

I've seen two examples of the following code fragement:

	while (accept(s, 0, 0) < 0) {
		...
	}

found in talk and X Windows.  Under our current socket implementation
this above code fragment will return EFAULT which seems entirely
reasonable to me since the second and third arguments to accept() are
suppose to be pointers to user memory for return values.

Since:

	struct sockaddr dummyaddr;
	int dummylen = sizeof struct sockaddr;

	accept(s, &dummyaddr, &dummylen);

seems more reasonable to me than having the kernel check for these two
sigularities (twoplearity?) I am wondering if this is actually
considered a feature that should be supported and accepted or if this
is just a hand me down that people have gotten use to.

BTW, passing a null pointer as the second or third argument to
accept() is not documented under any of the accept man pages I've read
(Ultrix and SunOs).

-- 
 "It took no computation to dance to the rock 'n roll station" -- VU
  ag@cbmvax.commodore.com     Keith M. Gabryelski      ...!uunet!cbmvax!ag

gwyn@smoke.BRL.MIL (Doug Gwyn) (09/18/89)

In article <7936@cbmvax.UUCP> ag@cbmvax.UUCP (Keith Gabryelski) writes:
>	while (accept(s, 0, 0) < 0) {
>BTW, passing a null pointer as the second or third argument to
>accept() is not documented under any of the accept man pages I've read

And in any case, those aren't null pointers, they're 0-valued integers.
On some systems this does matter.

net@tub.UUCP (Oliver Laumann) (09/19/89)

In article <7936@cbmvax.UUCP> ag@cbmvax.UUCP (Keith Gabryelski) writes:
> 	while (accept(s, 0, 0) < 0) {
> 
> I am wondering if this is actually considered a feature [..]

It's an undocumented feature of at least 4.3 BSD.  By the way, the call to
accept() should probably read "accept(s, (struct sockaddr *)0, (int *)0)".

--
Oliver Laumann              net@TUB.BITNET              net@tub.UUCP