Is this the correct?!

[vashwath]

Hi all,
Is this the corrrect method to determine if the procesor is little
endian or Big endian.
if((*(char*)&i)==1)
lil_end = TRUE;
else
lil_end = FALSE;

 

[Me]

Is this the corrrect method to determine if the procesor is little
endian or Big endian.
if((*(char*)&i)==1)
lil_end = TRUE;
else
lil_end = FALSE;

I'm assuming you've got a

int i = 1;

above, and no, there is *no* way to determine the bit order of a type
in C. Notice, I said *bit* order, not *byte* order. A type may have any
bit ordering it chooses and its bit order in relation to another type
may not match up in any meaningful way. This would be a pretty stupid,
but perfectly legal implementation. I can think of a tou of ways how
this test can pass or fail and it relies on behavior that may or may
not give the same result on the next run of the program.

IMHO, it's best to just think of C as having signed and unsigned
integer types with guaranteed minimum limits and being careful not to
overflow/underflow the signed integer types instead of trying to do
anything tricky.

 

[Martijn]

Hi all,
Is this the corrrect method to determine if the procesor is little
endian or Big endian.
if((*(char*)&i)==1)
lil_end = TRUE;
else
lil_end = FALSE;

Hmmm, there must be something missing here (or I am missing something )

What you could do, is write a long (such as 0x12345678) to memory, and read
it in byte by byte (I can think of at least three mappings, but in your case
just reading the first byte will probably suffice).

long l = 0x12345678;

if ( *(char*)&l == 0x12 )
/* big endian */
else
/* little endian */

Good luck,

 

[Peter Nilsson]

Hi all,
Is this the corrrect method to determine if the procesor is
little endian or Big endian.
if((*(char*)&i)==1)
lil_end = TRUE;
else
lil_end = FALSE;

Please read the FAQ before posting to clc...

http://www.eskimo.com/~scs/C-faq/q20.9.html

 

[Johny]

This will behave correctly.

#include <stdio.h>

int main(int argc,char *argv[])

{

union

{

short s;

char c[sizeof(short)];

}myUn;



myUn.s = 0x0102;

if(sizeof(short) == 2)

{

if(myUn.c[0] == 1 && myUn.c[1] == 2)

printf("\nBig Endian\n");

else if(myUn.c[0] == 2 && myUn.c[1] == 1)

printf("\nSmall Endian\n");

else

printf("\nNo Match\n");

}

else

printf("\nTry a data type whose size is 2\n");

return 0;

}

 

[Chris Torek]

Is this the corrrect method to determine if the procesor is little
endian or Big endian.

[method snipped; but see the FAQ]

What will you do on a PDP-11, which is both little and big endian
simultaneously? 32-bit values stored in a "long" are made of
two 16-bit values stored in big-endian order, where those two
16-bit values are themselves made of two 8-bit values stored in
little-endian order.

 

[joshc]

Please read the FAQ before posting to clc...

http://www.eskimo.com/~scs/C-faq/q20.9.html

Hmm, in light of the FAQ does that mean that "Me"'s explanation of the
bit ordering possibly being different false? In other words, will the
check for endianness as described in the faq work on any
implementation? What happens if sizeof char == sizeof int ? If they
were both 2 bytes wouldn't that test fail?

 

[Christian Bau]

Hmm, in light of the FAQ does that mean that "Me"'s explanation of the
bit ordering possibly being different false? In other words, will the
check for endianness as described in the faq work on any
implementation? What happens if sizeof char == sizeof int ? If they
were both 2 bytes wouldn't that test fail?

If both were 2 bytes then I can't say whether the test would fail or
pass, but I can tell you with certainty that you wouldn't be using a C
compiler.

The test could easily fail on implemenations that have padding bits. On
the other hand, there could be implementations where "little endian" and
"big endian" doesn't even make sense.

 

[Kenny McCormack]

Is this the corrrect method to determine if the procesor is little
endian or Big endian.

[method snipped; but see the FAQ]

What will you do on a PDP-11, which is both little and big endian
simultaneously? 32-bit values stored in a "long" are made of
two 16-bit values stored in big-endian order, where those two
16-bit values are themselves made of two 8-bit values stored in
little-endian order.

Can we please make it part of the religion of this NG that when people post
questions like this, they must also provide why they want to know?

I.e., we seem to do a pretty good job of stomping on them for all the OT
stuff, can't we also stomp on them for posting silly things w/o any
rationale given?

 

[joshc]

If both were 2 bytes then I can't say whether the test would fail or
pass, but I can tell you with certainty that you wouldn't be using a C
compiler.

I don't have the standard in front of me at this moment, but couldn't a
conforming implementation have sizeof char == sizeof int == 2? Care to
explain why you think otherwise?

As far as me personally when I read through this thread I wondered if
there indeed was a way of determining endianness in a portable way. I
certainly could see the benefit of determining endianness in an
embedded context.

 

[Mark McIntyre]

I don't have the standard in front of me at this moment, but couldn't a
conforming implementation have sizeof char == sizeof int == 2?

AFAIK an implementation with sizeof char == sizeof int would be legal,
but would have some big problems. Consider the case of getchar().

 

[Christian Bau]

If both were 2 bytes then I can't say whether the test would fail or
pass, but I can tell you with certainty that you wouldn't be using a C
compiler.

I don't have the standard in front of me at this moment, but couldn't a
conforming implementation have sizeof char == sizeof int == 2? Care to
explain why you think otherwise?[/QUOTE]

No. "char" is the unit in which sizes are measured. sizeof xxx == 2
means that xxx is as large as two chars. A char is always exactly as
large as a char, therefore sizeof (char) == 1.

As far as me personally when I read through this thread I wondered if
there indeed was a way of determining endianness in a portable way. I
certainly could see the benefit of determining endianness in an
embedded context.

Not portable. There may be non-portable methods that work on all
implementations that you are interested in. The usual solution is to use
some macro that is defined differently from implementation to
implementation.

 

[Dik T. Winter]

> I don't have the standard in front of me at this moment, but couldn't a
> conforming implementation have sizeof char == sizeof int == 2? Care to
> explain why you think otherwise?

sizeof char == sizeof int is certainly possible. sizeof char == 2 is
certainly *not* possible. sizeof char == 1 by definition.

 

[Kenny McCormack]

I don't have the standard in front of me at this moment, but couldn't a
conforming implementation have sizeof char == sizeof int == 2? Care to
explain why you think otherwise?

I'm sure that that is allowed. I think there was discussion pretty
recently about some implementation where everything was 32 bits (char, int,
long).

As far as me personally when I read through this thread I wondered if
there indeed was a way of determining endianness in a portable way. I
certainly could see the benefit of determining endianness in an
embedded context.

Really? How/why?

 

[Gordon Burditt]

If both were 2 bytes then I can't say whether the test would fail or

I'm sure that that is allowed. I think there was discussion pretty
recently about some implementation where everything was 32 bits (char, int,
long).

In that situation:
sizeof char = 1
sizeof int = 1
sizeof long = 1

sizeof char = 2 is never allowed.

Gordon L. Burditt

 

[joshc]

In that situation:

sizeof char = 1
sizeof int = 1
sizeof long = 1

sizeof char = 2 is never allowed.

Gordon L. Burditt

Yeah, good point. I guess what I intended to convey was the situation
where sizeof char is 16-bits or greater assuming a 2's complement
implementation, and sizeof char == sizeof int.

As far as why determining the endianness may be important, I often
write code to communicate among devices via SPI on devices where the
transmit buffer is 8 bits. Since I have to send data as a stream of
bytes, endianness becomes important. All the existing code assumes big
endian micros. We only use 2's complement implementations but I don't
see why we might not switch to a little-endian architecture.

 

[Martin Ambuhl]

I don't have the standard in front of me at this moment, but couldn't a
conforming implementation have sizeof char == sizeof int == 2?

No. sizeof(char) == 1 by definition.
If you think that sizeof() returns sizes in octets, you are wrong. It
yields sizes in terms of the byte, the amount of space that a char
occupies. If your char has 16 bits, then CHAR_BIT is 16, and a byte has
16 bits. Those 16-bit bytes could be made of two octets. Or not.

 

[CBFalconer]

.... snip ...

As far as why determining the endianness may be important, I often
write code to communicate among devices via SPI on devices where the
transmit buffer is 8 bits. Since I have to send data as a stream of
bytes, endianness becomes important. All the existing code assumes big
endian micros. We only use 2's complement implementations but I don't
see why we might not switch to a little-endian architecture.

Then you have all you need to know, i.e. the form during
transmission. All you have to do is write code that doesn't depend
on endianness. integer multiply and divide by 256 and masking to 8
bits seem appropriate. It doesn't even need to know anything about
byte size (CHAR_BIT).

When you are done you won't need any special code on any of your
machines, and you may appreciate the power of standards.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

 

[Chris Torek]

As far as why determining the endianness may be important, I often
write code to communicate among devices via SPI on devices where the
transmit buffer is 8 bits. Since I have to send data as a stream of
bytes, endianness becomes important.

In that case, do it yourself, so that you have control:

unsigned char message[SIZE];

... verify that "len" is in range, e.g., does not exceed 1023 ...
message[0] = FOO_CODE;
message[1] = (len >> 8) & 0xff; /* assumes len >= 0 */
message[2] = len & 0xff;
memcpy(&message[3], whatever, len);
send_SPI_data(..., message, len + 3);

This code works if your machine is little-endian, big-endian,
PDP-endian, or even My-Favorite-Martian-antenna-endian. It works
if your "char"s are 8 bits, or 9 bits, or 16 bits, or 32 bits
(provided send_SPI_data() can somehow manage to send the low 8 bits
of each "unsigned char" out to the appropriate device).

In short, it always works.

 

[Keith Thompson]

Yeah, good point. I guess what I intended to convey was the situation
where sizeof char is 16-bits or greater assuming a 2's complement
implementation, and sizeof char == sizeof int.

As far as why determining the endianness may be important, I often
write code to communicate among devices via SPI on devices where the
transmit buffer is 8 bits. Since I have to send data as a stream of
bytes, endianness becomes important. All the existing code assumes big
endian micros. We only use 2's complement implementations but I don't
see why we might not switch to a little-endian architecture.

There's a group of non-standard functions that handle conversions
between host byte order and network byte order. (Network byte order
is MSB first.) Look up htonl, htons, ntohl, and ntohs. If you need
more information than your system's documentation provides, try a
system-specific newsgroup such as comp.unix.programmer.