setsockopt(2) bug.
John T Kohl
jtkohl at athena.mit.edu
Sat May 7 03:16:05 AEST 1988
In article <514 at fornax.UUCP> stevec at fornax.UUCP (Steve Cumming) writes:
>
>Here's an interesting little glitch in the 4.3BSD socket handling code -
>specifically in the toggling of socket level options.
...
>What happens is that setsockopt(3) returns with EINVAL
>whenever a socket level boolean option is reset.
I believe what you are describing is correct behavior. Read on.
>Here's how to duplicate it:
> if (setsockopt(f, SOL_SOCKET, SO_REUSEADDR, (char *)0, sizeof(int)) < 0) {
The problem is the option value you are passing in should be a
POINTER to the desired value.
If you wish to turn the option on, make it point to a storage cell with
some non-zero value.
If you wish to turn the option OFF, make it point to a storage cell with
a value of zero:
int zero = 0;
if (setsockopt(f, SOL_SOCKET, SO_REUSEADDR,
(char *)&zero, sizeof(int)) < 0 {
>I quote from the manual entry for {get|set}sockopt(2):
> setsockopt(s,level,optname,optval,optlen)
> int s,level,optname;
> char *optval;
> int optlen;
> ...To manipulate options at the "socket" level,
> level is specified as SOL_SOCKET.
> The parameters optval and optlen are used to access option values
> for setsockopt. ... If not option value is to be supplied or
> returned, optval may be suppled as 0.
This is correct. In your test case you should supply an option value, zero or
non-zero.
> For setsockopt, the parameter should [be] non-zero to enable a boolean
> option, or zero if the option is be disabled.
> [SO_REUSEADDR is such an option]
I believe your fix is unnecessary, given a stricter interpretation of
the manual pages.
----
John Kohl
MIT/Project Athena
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list