djv@bedford.net wrote:
> --- cmds.c.orig	2007-01-24 22:33:51.000000000 -0500
> +++ cmds.c	2007-01-24 22:34:30.000000000 -0500
> @@ -483,10 +483,11 @@
>  		return(-1);
>  	}
>  
> +	memset(&sin, 0, sizeof sin);
>  	sin.sin_family = AF_INET;
>  	sin.sin_addr.s_addr = 0;
>  	for (port = IPPORT_RESERVED - 1; port > IPPORT_RESERVED / 2; port--) {
> -		sin.sin_port = htons((u_short)port);
> +		sin.sin_port = port;
>  		if (bind(sock, (struct sockaddr*)&sin, sizeof (sin)) >= 0)
>  			break;

Sorry, but I don't get this. In how far is htons() a bug here? It certainly
never mattered for a big-endian machine but on a little endian machine it
definitely does. Albeit I'm having trouble to find this in the documentation,
sin_port has to be initialized using big-endian (network byte order). For
raw sockets this might differ but this is an UDP socket.

> Eliminating the htons call on little-endian machines results in a port
> assignment in the 0-1023 range as demanded by some hosts, and as appears to
> be the intent of the programmer.

I don't see how unless I'm missing something.

-- 
Christian