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.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
In fact there is no difference; the implementations perform the same task.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.
Last edited by Dave Evans; 11-10-2007 at 10:36 AM.
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...
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.
Last edited by Dave Evans; 11-11-2007 at 09:30 AM.
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.
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.
EDIT: Bad example. Suppose it was BCDA instead.
Last edited by brewbuck; 11-11-2007 at 10:58 PM.
That's exactly the kind of thing I was wondering about.
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.
