Endianness programme help

This is a discussion on Endianness programme help within the C Programming forums, part of the General Programming Boards category; Hello Everyone,
How can i write the c code to check whether my machine is little indian or big indian????
...

As to converting, you just reassemble the bytes in the opposite order (and you can peel off the bytes using pointers as above). Generally you only do this if you need to communicate between machines, and if so, then using something like htons and friends would be the Right Thing to do.

As to converting, you just reassemble the bytes in the opposite order (and you can peel off the bytes using pointers as above). Generally you only do this if you need to communicate between machines, and if so, then using something like htons and friends would be the Right Thing to do.

Yes, I have fixed the missing & - too much typing, not enough thinking, as per usual!

htons() and such functions are definitely the best solution. Many processors have clever instructions that do (or at least help) convert byte-order, so writing your own function to read/write the bytes is not a good idea.

We are assuming there are only two kinds of machines... lsb -> msb and the reverse. But what about those whose 16-bit words may be in one order yet the bytes are in another. Or similarly with 32-bit or 64-bit sub chunks may not necessarily be bytes in simple ascending or descending major order.

I propose that the machine's byte order be expressed as a bit flag value: for example, the trivial cases above would be represented as 0000 or 1111. Such an indicator might be embedded in any files that are expected to be portable across platforms to tell the resident system how the data is to be interpreted.

We are assuming there are only two kinds of machines... lsb -> msb and the reverse. But what about those whose 16-bit words may be in one order yet the bytes are in another. Or similarly with 32-bit or 64-bit sub chunks may not necessarily be bytes in simple ascending or descending major order.

I find it very unlikely that a machine would use different endianness for different data sizes. And having something else like 2301 ordering seems even less likely.

If I were you, I'd write most of my code as portably as possible, and have a few wrapper functions to convert between types which just use e.g. htons() etc. Then if you actually encounter such a bizarre machine as you have described, you can modify these wrapper functions as necessary.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Still other architectures, generically called middle-endian or mixed-endian, may have a more complicated ordering; PDP-11, for instance, stored some 32-bit words, counting from the most significant, as: 2nd byte first, then 1st, then 4th, and finally 3rd.

Note that this can be interpreted as storing the most significant "half" (16-bits) followed by the less significant half (as if big-endian) but with each half stored in little-endian format. This ordering is known as PDP-endianness.

The ARM architecture can also produce this format when writing a 32-bit word to an address 2 bytes from a 32-bit word alignment.

But I still think that this is a very platform-specific problem which can be solved by writing platform-specific code for your program. I don't think (but watch me be wrong again :P) that your code would necessarily need to deal with all these kinds of endianness in one compiled binary program. I could see you needing to deal with the "local" endianness as well as a "generic", platform-independent endianness for reading binary data files or transferring data over a network, for example; but does your one program need to be able to read PDP-endianness and big-endianness data without being re-compiled?

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

The second part of the originally stated problem has not as yet been addressed. How to convert one endienness to another.

I would suggest that once the transformation vector is found, to loop through the bytes of the source 32-bit integer and transposing them using it as guide. This would also require the knowledge of the source endienness as well to find the complete transpose permutation.