setsockopt(2) bug.

[John T Kohl]

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