Hmm. This may be overkill, but here is my crossposted reply to the
crossposted post. (HI TODD! :-)

> From: Todd Vierling <tv@pobox.com>
>
> [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.


Interesting theory...I'm kind of intrigued as to how you got there.

Those are what I call ``legacy longs'', or 32-bit objects. It's just a bad
name, these days. (This is all because DEC called int16_t a ``word'' on
the VAX, darn it!)

Even if you do call htonl(3) on a real alpha long, it still does what you
expect, and does everything in the low order 32 bits.

        0x0000000011223344      <->     0x0000000044332211
        0x11223344              <->     0x44332211

The only time you see something like 0x4433221100000000 is if you are
looking at an LP64 long or ILP32 ``long long'' from a foreign and opposite
swizzle machine. But this doesn't actually happen in any network code I've
seen, and in any case it isn't valid input to htonl which will completely
butcher it, leaving you with zero as it swizzles just the lower 32 bits.

        Ross.Harvey@Computer.Org