> struct sockaddr_in sin;
>
> len = sizeof(sin);
> fd = accept(s, (struct sockaddr *)&sin, &len);
> if (fd == -1)
> err(1, "accept");
> printf("peer address: %s\n", inet_ntoa(sin.sin_addr));
>
>The bug with this code is that it blindly uses ``sin'' after accept
>returns, since the usage of the returned sockaddr must first be qualified
>by checking the returned value of len. Current behavior is for accept
>to return a valid fd, and set len to 0.
>
>To my knowledge, most applications (certainly those I inspected) do not
>bother to check 'len' before using 'sin', and thus do the wrong thing;
>this is the bug that BIND ran into. (just to be clear, this is a bug
>in the application code, not the kernel; although you could make the
>case that it is a documentation bug as well).
I wonder if we can call it an "application bug".
yes, it was application's fault that it did not check sa_len.
from the text below:
http://www.opengroup.org/onlinepubs/007908799/xns/accept.html
i'm not sure if it is legal to return zero-length sockaddr when
the kernel is given enough space to return the sockaddr.
(the last paragraph do not fit to TCP)
itojun
If address is not a null pointer, the address of the peer for the accepted
connection is stored in the sockaddr structure pointed to by address, and
the length of this address is stored in the object pointed to by
address_len.
If the actual length of the address is greater than the length of the
supplied sockaddr structure, the stored address will be truncated.
If the protocol permits connections by unbound clients, and the peer is not
bound, then the value stored in the object pointed to by address is
unspecified.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
