> ...which is not compatible with POSIX declaration:
> http://www.opengroup.org/onlinepubs/009695399/functions/htonl.html
> 
> SYNOPSIS
> 	#include <arpa/inet.h>
>  
> 	 uint32_t htonl(uint32_t hostlong);
> 	 uint16_t htons(uint16_t hostshort);
> 	 uint32_t ntohl(uint32_t netlong);
> 	 uint16_t ntohs(uint16_t netshort);

I was at one of the XNET meetings where these functions were discussed.
I didn't bother pushing the point too far that the types in htons() are
largely wrong - just because the domain of an argument is 0..65535
doesn't mean that the type has to be explicitly 16bit.

Indeed on a big-endian system htons() is often implemented as:
#define htons(x) (x)
and on a little endian one as:
#define htons(x) ((x) >> 8 | ((x) & 0xff) << 8))
neither of which honours the 16bit truncation implied by the prototypes.

In general (always?) you would get better code if htons() were:
	uint32_t htons(uint32_t);
maybe the 'fast' type should have need used - although the C99 names
for those type were still in flux at the time XNS5 was done.

	David

-- 
David Laight: david@l8s.co.uk