Subject: accept() call
To: None <tech-net@NetBSD.ORG>
From: Christian Kuhtz <email@example.com>
Date: 02/04/1997 00:59:00
[god, I hope this isn't just yet another late night lapsus]
Anyone out there who'd be willing to have a look at this C code snippet and
tell me why the second one works and the first one doesn't? I've been banging
my head against this and can't figure it out... *argh*
Here's the variable declaration:
int socket, new_socket, cli_len;
struct sockaddr_in cli_addr;
I. Version (works)
new_socket=accept(socket,(struct sockaddr *)&cli_addr,cli_len);
II. Version (doesn't work)
new_socket=accept(socket,(struct sockaddr *)&cli_addr,&sizeof(cli_addr));
Why is accept() declared as "int accept(int, struct sockaddr *, int *)" and
not "int accept(int, struct sockaddr *, int)"? Why can't I typecast this
silly argument without having to waste another temporary variable?
If it helps, gcc complains about "invalid lvalue in unary `&'".. I know what
that means, but it still doesn't make sense to me.
Heck, looking at the implementation in Rich Steven's TCP/IP Illustrated Vol
II, p. 458, it does even seem like it is using the third argument (retval) at
And it gets even better if you look at the BSD4.4 stack in
src/sys/kern/uipc_syscalls.c for sys_accept(). There's a line in the code that
goes like this:
*retval = tmpfd;
The only bloody time this is ever used..... *pulls hairs out*.. what's the
point in passing a pointer if you're going to dereference it anyway for all
that you're doing with it? Better yet, nothing's ever done with tmpfd or
retval after that, both being local to the procedure (well, sort of). And
since I have never seen anyone passing anything but sizeof() the sockaddr arg
down to accept(), what's the point?
Is it me who's missing something here or is this part of the Berkeley sockets
just plain braindead? Darn, I hate writing OS servers, I hate it, I hate it,
I hate it! Did I say that I hate it?
Christian Kuhtz <firstname.lastname@example.org>
".com is a mistake."