Hex: 10011001
This is what I was referring to, yes. For those who still don't get
it (and as I've pointed out privately more than a few times today),
it's a palindrome. Reads the same forwards as backwards. 15+ years
ago, people were impressed by that sort of thing.
Stephen
The binary equivalent of the hex is also a palindrome:
Bin: 10000000000010001000000000001
> Hex: 10011001
This is what I was referring to, yes. For those who still don't get
it (and as I've pointed out privately more than a few times today),
it's a palindrome. Reads the same forwards as backwards. 15+ years
ago, people were impressed by that sort of thing.Stephen
Best Regards,
Simon Higgs
The binary equivalent of the hex is also a palindrome:
Bin: 10000000000010001000000000001
you're missing 3 bits ! Assuming you want to add 3 trailing 0's this would
yield:
Hex: 80088008
Quad: 128.8.128.8
which is a palindrome alright, but not the same address Stepehn mentioned.
> > Hex: 10011001
Bin: 00010000000000010001000000000001
Not a palindrome 
>
>This is what I was referring to, yes. For those who still don't get
>it (and as I've pointed out privately more than a few times today),
>it's a palindrome. Reads the same forwards as backwards. 15+ years
>ago, people were impressed by that sort of thing.
Because it does not matter whether it's network byte order or not?
Mathias
In article <NEBBLGLDKLMMGKEMEFMFAEBNCFAA.mathias@koerber.org>,
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.