North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Statements against new.net?

  • From: Michael Shields
  • Date: Fri Mar 16 04:13:06 2001 
In article <[email protected]>,
"Mathias Koerber" <[email protected]> wrote:
> Because it does not matter whether it's network byte order or not?

16.1.16.1 is sensitive to network byte order; this program
demonstrates that:

    #include <stdio.h>
    #include <arpa/inet.h>
    #include <netinet/in.h>
    #include <sys/socket.h>

    int
    main(void)
    {
        struct in_addr sin;

        if (inet_aton("16.1.16.1", &sin) < 0) {
            perror("inet_aton failed");
            exit(1);
        }

        printf("Host byte order:    %10lu  0x%08lx\n",
               sin.s_addr, sin.s_addr);
        printf("Network byte order: %10lu  0x%08lx\n",
               htonl(sin.s_addr), htonl(sin.s_addr));

        return(0);
    }

On IA32 this outputs:

    Host byte order:      17826064  0x01100110
    Network byte order:  268505089  0x10011001

and on sun4c:

    Host byte order:     268505089  0x10011001
    Network byte order:  268505089  0x10011001

This occurs because the MSB vs. LSB conversion reorders at byte units,
but the mental reordering we perform while looking at a hexadecimal
representation occurs at the four-bit unit represented by one hex digit.

16.1.1.16 would be a palindrome at the byte level (0x10010110), and so
htonl() will be a no-op on it even on a little-endian machine.

I hope this clears things up.  Let's run some networks now.
-- 
Shields.