2

I don't think that the marked questions and answers do meet my expectations The link --> Same output for htonl() and ntohl() on an integer --> says Network byte order is big-endian, host byte order is little-endian. My confusion still goes on. Also, what is host? Still not answer most of my questions. I think those voted the question for closing have misunderstood my question I've voted to reopen. Please reread and reopen the question.

I've read that network-byte-order always is represented in Big Endian. However, I didn't found formal source for that. I did a snippet to see the difference between both functions but on the same machine I get same results.

#include <stdio.h>

int main() {
    //first part
    printf("%d\n", ntohs(12345));
    printf("%d\n", ntohs(12345) == 12345);
    // second part
    printf("%d\n", htons(12345));
    printf("%d\n", htons(12345) == 12345);
    //third part
    printf("%d\n", htons(htons(12345)));
    printf("%d\n", ntohs(ntohs(12345)));
    //fourth part
    printf("%d\n", ntohs(htons(12345)));
    return 0;
}
  • If network-byte-order always is represented in Big Endian, why cannot I read printed value as 12345 in second part? tl;dr My machine is little-endian.

After I tried same code also on PowerPC which works with Big Endian, both first part and second part give same result 12345. It is not interesting because of the machine's representation.

  • What about third part? Is it De Morgan(pun intended!)? It yields same result with fourth part. So, why do we need if both functions do same task?
  • What does it mean "host" in this context? My machine?
  • I though that I could use the functions to check whether a machine uses little-endian or big-endian. However, It doesn't sound sanely after the intricacies.

Little-Endian Computer Output: (Mac OSX)

14640
0
14640
0
12345
12345
12345

Big-Endian Computer Output: (PowerPC)

root@debian-powerpc:~# gcc -c endian.c 
root@debian-powerpc:~# gcc endian.c -o  out 
root@debian-powerpc:~# ./out 
12345
1
12345
1
12345
12345
12345
Soner from The Ottoman Empire
  • 18,731
  • 3
  • 79
  • 101
  • Thats multiple questions in one -> off-topic. Most are confused and unclear -> off-topic. Looks like you either didn't really rread the documentation or din't understand it, possibly due to lack of basics. Sometimes it's a good idea to step back and have a look at the whole picture. – too honest for this site Aug 02 '18 at 16:30
  • On a sidenote: your code invokes undefined behaviour, you're using wrong conversion type specifiers. So it does not show anything. – too honest for this site Aug 02 '18 at 16:31
  • @toohonestforthissite Because of the default argument promotions and the implicit declaration rules, there is no UB in this code. (In particular, passing a `short` quantity to printf's `%d` is perfectly fine.) It _ought_ to be including `` for declarations of `htons` and `ntohs`, though. – zwol Aug 02 '18 at 16:42
  • htons and ntohs do the same thing: they reverse bytes or they don't do anything, depending on the endianness of the host – Jean-François Fabre Aug 02 '18 at 16:44
  • @zwol: 7.21.6.1p9: "If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined" – too honest for this site Aug 02 '18 at 16:50
  • @toohonestforthissite 6.5.2.2p7 "... The ellipsis notation in a function prototype declarator causes argument type conversion to stop after the last declared parameter. The default argument promotions are performed on trailing arguments" Therefore, if an expression with type `short` is supplied as one of the variable arguments to `printf`, `printf` receives an `int`, which agrees with `%d`. – zwol Aug 02 '18 at 16:56
  • @zwol: This is wrong, as `uint16_t` could be `unsigned`, which is not the type expected by `%d`. The section I referenced is about that specific function's behaviour, not parameter passing **in general**. A function may very well specify more strict rules to valid parameters/conversions. – too honest for this site Aug 02 '18 at 17:04
  • @toohonestforthissite No, that is a misinterpretation. The rules of 6.5.2.2 apply first to all function calls, and in particular, default argument promotion happens for all parameters passed as "trailing arguments" for a variable argument list. Only then do the specific rules for a library function apply. Regarding the possibility that `uint16_t` might be `unsigned int` and therefore the code would have UB due to signed/unsigned mismatch, see https://stackoverflow.com/questions/4664100/does-printfx-1-invoke-undefined-behavior -- technically yes, practically no. – zwol Aug 02 '18 at 17:12
  • @zwol: "practically no" is a very weak position if there is absolutely no need to resort to it. What's the problem using the `inttypes.h` macro with the corrrect conversion type specifier? – too honest for this site Aug 02 '18 at 17:16
  • @Jean-FrançoisFabre Re; "htons and ntohs do the same thing". See this [good comment](https://stackoverflow.com/questions/11423338/same-output-for-htonl-and-ntohl-on-an-integer#comment15068730_11423371) – chux - Reinstate Monica Aug 02 '18 at 17:38
  • @Jean-FrançoisFabre **I respect your experiences but I don't think that the marked questions and answers do meet my expectations** The link --> https://stackoverflow.com/a/11423368/4990642 --> says _Network byte order is big-endian, host byte order is little-endian._ My confusion still goes on. Also, what is host? Still not answer most of my questions. **I think you have misunderstood my question** _**I've voted to reopen**_. Please reread and reopen the question. – Soner from The Ottoman Empire Aug 02 '18 at 17:38
  • 1
    @toohonestforthissite This is a test program. It does not need to be perfectly portable. OP wanted help understanding `htons` and `ntohs` and instead they got a bunch of natter in the comments about how their program might misbehave on a hypothetical 16-bit microcontroller whose calling convention treats `unsigned int` and `signed int` differently. Can you see how that's not the ideal outcome for anyone? – zwol Aug 02 '18 at 17:45
  • @snr You will have better luck if you ask a set of new questions, one question per post, being as specific as you can about what it is you still don't understand after having read the linked questions. – zwol Aug 02 '18 at 17:46
  • @zwol Really thanks for your interest. But, **I don't write my questions giddy-pacedly** I thought and read on it for hours. I've read the both links before asking the question. One of the answers on former link says _Network byte order is big-endian, host byte order is little-endian._ However, the person closed the topic says _htons and ntohs do the same thing: they reverse bytes or they don't do anything, depending on the endianness of the host_. What is my wrong here about asking the question? – Soner from The Ottoman Empire Aug 02 '18 at 17:49
  • @snr Re; "why do we need if both functions do same task?" --> review [good comment](https://stackoverflow.com/questions/11423338/same-output-for-htonl-and-ntohl-on-an-integer#comment15068730_11423371) and [this](https://stackoverflow.com/questions/11423338/same-output-for-htonl-and-ntohl-on-an-integer#comment15068788_11423371). – chux - Reinstate Monica Aug 02 '18 at 17:57
  • @chux why don't `printf("%d\n", htons(12345));` print `12345` if If network-byte-order always is represented in Big Endian? – Soner from The Ottoman Empire Aug 02 '18 at 18:00
  • @snr The biggest problem with this post is that you're trying to ask several questions at once. We want you to ask exactly one question per post. – zwol Aug 02 '18 at 18:00
  • 1
    there are several gold badge owners who can single-handledly reopen the question if they feel it's not a duplicate (they already gave very good advice on the question). I'm not going to reopen, personally. – Jean-François Fabre Aug 02 '18 at 18:01
  • @snr [comment](https://stackoverflow.com/questions/51658339/difference-between-htons-and-ntohs-function-in-c?noredirect=1#comment90282843_51658339) is unclear as posted in the question, the BE machine _did_ print `12345` as expected. Are you asking why it printed something else on the LE MAC? Yet I see the comments getting out of hand. [TTFN](https://en.wikipedia.org/wiki/TTFN). – chux - Reinstate Monica Aug 02 '18 at 18:09
  • @chux Yes, I'm mentioning LE MAC. I think it would also print `12345` instead of `14640`. Because `htons` converts to BE format always?? – Soner from The Ottoman Empire Aug 02 '18 at 18:20
  • @snr The `htons` function converts to BE format always so long as its input is in the host byte order. Garbage in, garbage out. – David Schwartz Aug 02 '18 at 18:25
  • 3
    @snr `ntohs(12345)` did convert 12345 (stored in LE format on the MAC) into a 2-byte BE bit pattern and extended it to 4-bytes. The trouble was that code then gave this BE bit pattern to `printf()`, which expected to receive a `int` value in LE order. So code rather than printing 12345 (0x3039), printed 14640 (0x3930). A good idea is to 1) separate the idea of value from encoding and 2) investigate with `%x` and hexadecimal constants. – chux - Reinstate Monica Aug 02 '18 at 18:57

0 Answers0