Endianness conversion of data

unsigned int convertEndianness(unsigned int data) {
 char * c;
 char temp;
 unsigned int test = 0x000000FF;

 if((char*)(&test)[0] == (char)(0xFF)) // this machine is little endian
 {
  c = (char*)(&data);
  temp = c[0];
  c[0] = c[3];
  c[3] = temp;
  temp = c[1];
  c[1] = c[2];
  c[2] = temp;
 }
 return data;
}

When programming across networks it is often necessary to transfer data between a machine that is little endian and a machine that is big endian. See the Wikipedia entry for more information on the subject.

Generally network transmission should be in big endian. This function will prep data for sending across the network and do the reverse for data recieved across the network. This way the endianness of the opposite machine does not matter. First it checks to see if the first byte is the same as the least significant byte. If this is the case then the machine is little endian and the data must be converted.

Nice trick to automatically compile for the endianness of the local machine!

There's an x86 instruction for swapping endianness quickly: bswap.

cool. never noticed this one

I basically never use assembly so I didn't know about that, but the whole point of the function was to be as portable as possible, I figure if I don't know the endianness of the machine I probably wont know the archetecture either. You are right though, if this is used in a performance critical location it is better to sacrifice readability in order to put in multiple code paths in so you can use the assembly of each architecture. The apps I was writing were not proccessor bound on network transmission though, so I didn't have to worry about optomization.

You could also simply use htonl and the likes.

c = (char*)(&data);
if(c[0] == (char)(data % 256)) // this machine is little endian

I don't think thats a good idea. Think about a value like 0xFFABCDFF. The above code will determine the 'machine' to be little endian, although it doesn't necessary need to be. You basically compare the first byte of the value with the total value modulo 256. This will lead to potentially wrong results if the first and last byte are identical.

Or am I missing the obvious?? It's still early morning :)

No, I think that's a bug. You should do the check on some known data, such as:

bool isLittleEndian() { int foo=1; return 1==*((char*)&foo); }

Or just use htonl etc...

There is an error in the code but that is not it. I modulus by 256 to zero out the other bytes, but this would not work if the lower byte is zero already. I will fix the code to accomidate this.

I suppose even better I could use

#define LITTLE_ENDIAN ((0xFF000000 >> 24) & (255))

Originally Posted by NomadRock

I suppose even better I could use

#define LITTLE_ENDIAN ((0x000000FF << 24) & (0xFF000000))

[snapback]11708[/snapback]

No.

Ok, what is wrong with that?

It doesn't return 0 for big endian machines.

Quite true, good catch. Corrected as such. I really wish I didn't have to worry too much about the low level, but it is a good learning experience. Hopefully others can learn from this too.

BTW, I checked up on htonl, this is basically what I attempt to implement. Unfortunatly I do not have endian.h where it is supposed to reside on my mingw compiler. Is this a linux only include?

Here's what you can do:

unsigned char myFakeWORD[2] = { 0xFF, 0x00 };
  unsigned short myRealWORD = *((unsigned short*)myFakeWORD);
  if(myRealWORD == 0xFF00)
  {
    printf("we are in BIG ENDIAN baby!");
  }
  else
  {
    printf("oh crap...not LITTLE ENDIAN! Who invented this shit!?");
  }

damn I think I should pay more attention before posting...
sorry for stating the already stated

You could include one of the WinSock headers.

The whole idea is for this to work outside of windows x86 systems as well as on those systems.

I was writing an app in C that could be compiled on windows, linux, or solaris.

htonl etc are available on basically every platform that has a BSD-style socket interface.

I wanted to try and avoid a page of #if / #includes to find the right headers on any system

If you would restrict your set of a platforms to the relevant (quasi)standard, and the relevant (quasi)standard would enforce the existance of certain header files, that was possible. <wink>