Subject: Re: htonl and longs
To: Simon Burge <simonb@netbsd.org>
From: Todd Vierling <tv@pobox.com>
List: port-alpha
Date: 06/18/1999 09:28:51
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.

On a little-endian ILP32 machine, the integer 0x11223344 is represented by
0x44332211 in memory, and is stored as 0x11223344 after running through
htonl() (this is the usual, expected behavior).

On little-endian LP64, it's a little more strange.  The integer 0x11223344
is represented by 0x4433221100000000 in memory, and after running through
htonl(), becomes 0x0000000011223344.

If the unsigned long above should be machine, independent, then the htonl()
has to be calculated on a *LOCAL* long variable (otherwise you'll lose the
necessary 32 bits on the first store), and then stored into a u_int32_t in
the structure.

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.

This reminds me ... I'd like to raise my own objection to {h,n}to{n,h}q()
as you described a need for generic, NOT network-stack-only, interpretation
of 64-bit reversal.  This was brought up before, and it was generally
decided that a new naming scheme for generic functions, expressed in terms
of bswap*(), and capable of converting to and from both big and little
endian, was needed.

-- 
-- Todd Vierling (tv@pobox.com)