[From a post to port-alpha, so that the people watching the thread here see
it:]

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.

[...]

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)