Printable View
Does anyone know if there's any difference between htonl() & ntohl(), or are they just 2 functions that do the same thing with different names?
From what I can tell, on a Little Endian machine, they both take bytes ABCD and change them to DCBA.
Other than for symmetry & logical readability, is there any circumstance where it would make a difference which one you call when sending or receiving data over a network?
I believe it depends upon whether you are building from a LE implementation or a BE implementation. If you want your code to do the same thing on both, YMMV.
They guarantee that ABCD on the network is still represented as ABCD on the local machine, independent of the endian-ess of the local machine.
On some machines, they basically do nothing. On others, they rearrange all the bytes.
htonl = Host TO Network Long, converts a long from host byte order to network byte order
ntohl = Network TO Host Long, you get the idea.
There are also the short versions as well.
You use 'hton' when you're about to send stuff over the wire, and 'ntoh' to convert the data on the wire into a form you can use.
In fact there is no difference; the implementations perform the same task.Quote:
Originally Posted by cpjust
For both htonl() and ntohl() operating on 32-bit integer data types:
Little-endian architecture ==> swap bytes
Big-endian architecture ==> output is same as input
For purposes of self-documentation (human-readability), I would think you should use the name that corresponds to the functionality.
D.
Thanks. That's what I thought, but wasn't quite sure if using htonl() on receive instead of ntohl() could cause problems on some systems...Quote:
Originally Posted by Dave Evans
Quote:
Originally Posted by cpjust
Here's a thought: Why would you (or anyone else, for that matter) use htonl() on receive?
Even though I said that the two implementations have the same results (a statement based on my personal experience and my personal research), shouldn't the fact that there are two different functions for the two different directions motivate you to use the "right" one?
D.
Well normally I would use the properly named function for send or receive; but from what I can tell, those functions aren't part of the standard library, so some platforms might not have them. In that case, I'd have to write my own htonl() function. So I was wondering if I needed to implement those custom htonl() & ntohl() functions differently.
What platform has sockets and not htonl/ntohl?
I'll get you started.Quote:
Originally Posted by cpjust
A possible Game Plan:
1. Write the specification for htonl()
2. Implement it
3. Write the specification for ntohl()
4. If (3) is identical to (1), then what? If (3) is different from (1) then what?
D.
What if my machine represented that value as BADC? If ABCD and DCBA are the only options, then yes, they do the same thing. But in theory, any byte ordering is possible and so we need two separate functions.Quote:
Originally Posted by cpjust
EDIT: Bad example. Suppose it was BCDA instead.
That's exactly the kind of thing I was wondering about.Quote:
Originally Posted by brewbuck
Are there any computers that use a different Endian other than Little or Big?
I just fixed a bug while porting some code to Linux by adding calls to htonl()/ntohl()... I then added a header file which #includes the proper headers for htonl()... based on which platform was #defined.
I then added a note saying, if the platform being ported to doesn't have a htonl() function, use my custom Big <-> Little Endian conversion function. But of course, if the platform is neither Big nor Little Endian, then my function won't work properly.