In article <NEBBLGLDKLMMGKEMEFMFAEBNCFAA.mathias@koerber.org>, "Mathias Koerber" <mathias@koerber.org> 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.