Programming

Sure, the issue with big/little endian is their storage in memory. So "\001\000\000\000" sets up four bytes of memory, this could also be done as

char buffer[]={1,0,0,0};

but the string approach allows it to be done inline and use octel encoding, hence the three digits per byte.

Then we try and read a short from that area of memory, now we actually don't know how big a short is, but it's unlikely to be more than four bytes, the spec only says that a short should not be longer than a long, so casting it to a (const short *) means this is a pointer to a short, then the preceeding * gets the value of at that pointer.

If this was a big-endian machine it would have loaded 0x0100 into the short, if it was little-endian it would have loaded 0x0001.

In the very rare case that a short was 4 bytes, then the big-endian machine would have loaded 0x01000000 hence the test for < 256.

porter, thank it's clear now except for one thing:
Why doesn't "\001\000\000\000" get stored as a string like { '\', '0', '0', '1', '\', '0', '0', '0', '\' ..... '\0' } is it because "\001" is implicitly converted to an octal value of 1. Also, would "\00112\000\000\000" cause an overflow?

Yes.

That would be

0x01, 0x31, 0x32, 0x00,0x00,0x00

so an overflow of what?

Got it. Thanks!