[Vm-dev] The byte order fallacy

[Ben Coman]

I bumped into an interesting article [1] by Rob Pike that...
i = *((int*)data);
#ifdef BIG_ENDIAN
/* swap the bytes */
i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) |
(((i>>24)&0xFF)<<0);
#endif

is the wrong way to handle endianness since...
  "It assumes integers are addressable at any byte offset; on some machines
that's not true."
  "It depends on integers being 32 bits long, or requires more #ifdefs to
pick a 32-bit integer type."

I guess some people here have byte-ordering war wounds so I'd value your
opinion on whether I should file that as good advice.
I notice we have a couple of instances of this...

$  find platforms -name "*.c" -exec grep -Hi "<<" {} \; | grep ">>" | grep
24 | grep 8
./win32/plugins/FontPlugin/sqWin32FontPlugin.c:  #define BYTE_SWAP(w) ((w
<< 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24))
./win32/vm/sqWin32Window.c:   #define BYTE_SWAP(w) w = (w<<24) |
((w&0xFF00)<<8) | ((w>>8)&0xFF00) | (w>>24)

cheers -ben

[1] https://commandcenter.blogspot.com.au/2012/04/byte-order-fallacy.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170613/9b9a983a/attachment.html>