Todd Vierling wrote:

> On Fri, 18 Jun 1999, Simon Burge wrote:
> 
> : I'm looking at making the fortune data files byte-order and word-size
> : independant, and came across the following in fortune's .dat convertor:
> : 
> : 	simonpc:games/fortune/strfile 32> grep str_version *
> : 	strfile.c:      Tbl.str_version = VERSION;
> : 	strfile.c:      Tbl.str_version = htonl(Tbl.str_version);
> : 	strfile.h:      unsigned long   str_version;            /* version number */
> : 
> : Given that htonl is defined to work on the equivalent of u_int32_t's and
> : unsigned longs are 64 bits, and I right in assuming that the behaviour
> : of this bit of code is bogus at best?
> 
> htonl works on longs, not u_int32_t's.  This may sound Odd at first, but
> it's absolutely true.

That doesn't gell with <xxxx/endian.h>.  From the alpha endian.h:

	typedef u_int32_t in_addr_t;
	typedef u_int16_t in_port_t;

	__BEGIN_DECLS
	in_addr_t       htonl __P((in_addr_t)) __attribute__((__const__));
	in_port_t       htons __P((in_port_t)) __attribute__((__const__));
	in_addr_t       ntohl __P((in_addr_t)) __attribute__((__const__));
	in_port_t       ntohs __P((in_port_t)) __attribute__((__const__));
	__END_DECLS

The actual problem that lead me to this was code using htonl() on an
off_t (which is 64 bits).

> htonl() is NOT intended to do anything but work with `unsigned long' in a
> networking interpretation.  Other code that uses it should be shot with
> great vengeance.

The strfile(8) manpage mentions that all fields of a certain header are
in "network byte order".  Maybe that should be "xxx endian" instead,
probably big endian because that's "closest" to network byte order...

[reply to ?to?q() on tech-userlevel.]

Simon.