Endian Independence

[Barry Schwarz]

#include<stdio.h>

#define LITTLE_ENDIAN 0
#define BIG_ENDIAN 1

int endian() {
int i = 1;
char *p = (char *)&i;

if (p[0] == 1)
return LITTLE_ENDIAN;
else
return BIG_ENDIAN;
}


int reverseInt (int i) {
unsigned char c1, c2, c3, c4;

if ( endian() == BIG_ENDIAN ) {
return i;
} else {
c1 = i & 255;
c2 = (i >> 8) & 255;
c3 = (i >> 16) & 255;
c4 = (i >> 24) & 255;

return ((int)c1 << 24) + ((int)c2 << 16) + ((int)c3 << 8) + c4;
}
}

int main(void)
{
if(endian())
puts("Big Endian Machine");
else
puts("Small Endian Machine");
printf("%d",reverseInt(5));
return 0;

}

I tested it on my PC (On Pentium 4) and this is the output:

Small Endian Machine
83886080.

I am baffled as I was expecting 5 to be printed or is it that I am
missing something completely ?

What you are missing is that the bitwise functions (&, |, <<, >>)
operate on values and not on representations.

Your computation for c1 produces a value of 0x05. Your Pentium is
little-endian and the value passed to reverseInt is stored in memory
as 0x05000000. The value 255 is stored in memory as 0xff000000.
Anding the two produces 0x05000000. The low order byte is then stored
in c1.

In the return statement, the value calculated is 0x05000000 but it is
stored in memory as 0x00000005.

Probably i have completely misunderstood the idea of endianness

No, you just applied it in an inappropriate manner.


Remove del for email

 

[Richard]

Those who export for external consumption binary integers in non-bigendian
format invoke undefined behavior, like have daemons forced through their
nose, or having large anvils dropped on their head.

Heed the logic of self-preservation.

Maybe I'm slow today but I didn't understand a word of what you just
said or have a clue as to what you are suggesting.

And I'm still to say a clear and concise answer to Endian issues.

The bottom line is that any program which feeds on an externally
produced binary file must surely know the endianness of the data
therein. And the unit sizes.

 

[Nick Keighley]

isn't that what he said? "Transferring binary values through a file"
includes reading the values.

Heathfield said something similar a while back.

to whom? Twink or Lew Pitcher?

I was shocked. Yes,
"system specific" etc but to try an claim "portable C" deals with endian
issues is garbage from what I've seen attempted in the real world.

?? I've had to worry about endianess in data transferred between
machines. In what way is this not "real world". Admittedly doing
in text tends to avoid the problem.


--
Nick Keighley

Unpredictability may be exciting, but I don't believe it constitutes
good programming practice.
Richard Heathfield

 

[Nick Keighley]

this makes no sense. Why not little endian or DEC's strange
"endian" format? The two ends simply have to agree.

Maybe I'm slow today but I didn't understand a word of what you just
said or have a clue as to what you are suggesting.

I thought I understood it. I thought it was wrong.

And I'm still to say a clear and concise answer to Endian issues.

The bottom line is that any program which feeds on an externally
produced binary file must surely know the endianness of the data
therein. And the unit sizes

yes.

I must have misunderstood one of your earlier posts where
I thought you contradicted this advice. My apologies.

 

[Richard]

isn't that what he said? "Transferring binary values through a file"
includes reading the values.



to whom? Twink or Lew Pitcher?



?? I've had to worry about endianess in data transferred between
machines. In what way is this not "real world". Admittedly doing
in text tends to avoid the problem.

Yes, so have I. And the program needed to be told which way things
were. And using text is laughable in many cases.

 

[Richard Bos]

?? I've had to worry about endianess in data transferred between
machines. In what way is this not "real world". Admittedly doing
in text tends to avoid the problem.

How? If you write your code correctly, the only thing you have to worry
about is the endianness of the data _in the file_. But that does not
involve finding out the endianness of the machine.
The important thing to realise here is that the shift operators work on
values, not on representations, so the same shifts in the same order can
be used on a big-endian machine as on a small- or muddle-endian one,
provided you use the shifts in the right order for the endianness that
is required _by the file format_.
(And, of course, fwrite()ing binary data directly to a file is already a
bad idea for various other reasons, if you want to share the file.)

Richard