Log in

No account? Create an account

No more autoconf for endianess detection - Journal of Omnifarious

Sep. 10th, 2009

08:27 am - No more autoconf for endianess detection

Previous Entry Share Next Entry

autoconf is annoying to work with, and I think that programs that rely excessively on it for cross platform compatibility have issues of their own. Sometimes you really have no choice though.

Fortunately I recently discovered one place where I now do have a choice where I didn't before. This little code snippet can be optimized by gcc at compile time into a constant expression. That means that gcc realizes there is only one possible result and it uses that result in place of actually running the code in the function. Here is the code snippet:

inline bool is_little_endian()
   const union {
      ::std::tr1::uint32_t tval;
      unsigned char tchar[4];
   } testunion = { 0x11223344ul };
   return testunion.tchar[0] == 0x44u;

This is guaranteed to work on C99 systems, and, as I said, gcc is capable of recognizing it as a constant expression. This also means that if you have code like this:

   if (is_little_endian()) {
   } else {

gcc will be smart enough to see that only one branch of that if will ever be taken and optimize the other completely out of your code.

Normally you'd want to use autoconf for this so you will have a preprocessor macro that will elide the code for you. The fact gcc can optimize this well means you don't have to do that to get efficient code.

Current Location: 2237 NW 62nd ST, 98107
Current Mood: [mood icon] pleased


[User Picture]
Date:September 11th, 2009 04:36 am (UTC)
Hmm. I hope do_something_else doesn't choke on mixed-endian hardware.
(Reply) (Thread)
[User Picture]
Date:September 11th, 2009 10:17 am (UTC)

*chuckle* Well, yes. And just because 0x44u is first doesn't mean that 0x33u is next, so do_something() could have problems too. That code only covers 99.9% of the hardware out there. I'm sure there are some strange byte orders lurking around somewhere.

I could test explicitly (and fully) for one byte ordering or the other and throw an exception if it was neither. It would be interesting to see if gcc could optimize that sufficiently.

Edited at 2009-09-11 10:18 am (UTC)
(Reply) (Parent) (Thread)