<div dir="ltr">I bumped into an interesting article [1] by Rob Pike that... <div><div>i = *((int*)data);</div><div>#<span class="" id="gmail-:19h.1" tabindex="-1">ifdef</span> BIG_<span class="" id="gmail-:19h.2" tabindex="-1">ENDIAN</span></div><div>/* swap the bytes */</div><div>i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) | (((i>>24)&0xFF)<<0);</div><div>#<span class="" id="gmail-:19h.3" tabindex="-1">endif</span></div></div><div><br></div><div>is the wrong way to handle endianness since... </div><div>  "It assumes integers are addressable at any byte offset; on some machines that's not true."</div><div><div><div><div>  "It depends on integers being 32 bits long, or requires more #<span class="" id="gmail-:19h.5" tabindex="-1">ifdefs</span> to pick a 32-bit integer type."</div></div><div><br></div><div>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.</div></div><div>I notice we have a couple of instances of this...</div><div><br></div><div>$  find platforms -name "*.c" -exec grep -Hi "<<" {} \; | grep ">>" | grep 24 | grep 8</div><div><div>./win32/<span class="" id="gmail-:19h.9" tabindex="-1">plugins</span>/<span class="" id="gmail-:19h.10" tabindex="-1">FontPlugin</span>/sqWin32FontPlugin.c:  #define BYTE_SWAP(w) ((w << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24))<br></div><div>./win32/<span class="" id="gmail-:19h.11" tabindex="-1">vm</span>/sqWin32Window.c:   #define BYTE_SWAP(w) w = (w<<24) | ((w&0xFF00)<<8) | ((w>>8)&0xFF00) | (w>>24)</div></div></div><div><br></div><div>cheers -ben</div><div><br></div><div>[1] https://<span class="" id="gmail-:19h.12" tabindex="-1">commandcenter</span>.<span class="" id="gmail-:19h.13" tabindex="-1">blogspot</span>.com.<span class="" id="gmail-:19h.14" tabindex="-1">au</span>/2012/04/byte-order-fallacy.html</div><div><br></div></div>