Hello:

[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)

      cli_len=sizeof(cli_addr);
      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  
all!
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?

*Arrrrrgh*
--
Christian Kuhtz <ckuhtz@paranet.com>
                                                          ".com is a mistake."