> hi folks
> I am new to this group.i need to know how i can find the endianness of
> my system.help me out.
The best way is not to ask the question in the first place.
Write code that doesn't care about endianness -- more generally,
that cares only about the values and not about how they are
Sometimes the best way isn't practical (although IMHO it
*is* practical far more often than people seem to think). In
that case, the second-best way to find out is to read your
Sometimes even the second-best way won't do; you might
need a method suitable for use by the running program. The
third-best way is to store selected values into an `int' (or
whatever) and then inspect the individual bytes for clues.
Be warned: There are more than two possibilities! There are,
for example, twenty-four ways to arrange the bytes of a four-
byte `int', and at least three of them have been used in real
The worst way of all is to imagine that you know the answer
without needing to ask.
int n = 0x04030201;
char *s = (char *)&n;
printf("%d%d%d%d\n", s, s, s, s);
This will print '4321' on a big-endian system, like a mac G5 or a SUN
SPARC. On a pc it will print '1234', meaning it's little-endian. You
can of course simplify this into only two bytes if you like, it's just
what I had floating around on my disk. Depends on what you're using it
for, because then you can't see if it's a 'middle-endian' cpu (on a
PDP-11 it should print '3412', but those are rare anyway.
Hope this was what you meant. The clue is to cast the address of an int
or short to (void *) or (char *), because then it won't get converted
into the big-endian order when you print it.
int n = 0x04030201;
char *s = (void *)&n;
> bush wrote:
>> hi folks
>> I am new to this group.i need to know how i can find the endianness of
>> my system.help me out.
> The best way is not to ask the question in the first place.
> Write code that doesn't care about endianness -- more generally,
> that cares only about the values and not about how they are
That's fine, if your code is C, and C alone. However, for performance
reasons, it is sometimes convenient to invoke assembly language functions
- and then, taking endianness into account matters.
1) I did mention that the strait and narrow way is not
2) While there are sometimes reasons to stray from the
strait and narrow, in my experience the need to chit-chat
with other languages *on the same machine* has not been
among them. YMMV, of course, but discussions of the unpleasant
particulars probably belong on system-specific newsgroups.
Unlikely, at least as far as the C code is concerned. The assembly
programmer will know the byte order of the architecture and it is rather
unlikely that the C implementation will use a different byte order to
this. So if, for example, you pass an int (somehow) to an assembly routine
you'll end up with a "word", value in a register or whatever in the
correct byte order for the assembly code to use. There is no need for the
code to incorporate any explicit knowledge of byte order. When it is
needed explicitly it is typically the responsibility of the assembly
code to do the right thing rather than the C code.
Consider for example that an implementation could implement standard
library functions in assembly, so your C code might be calling code
written in assembly without you even being aware of it. It just works as
far as the C code is concerned.
(Only) if char is 8 bits, which is true of nearly all platforms
including those you named but not all and not required by the C
standard; and there are no embedded or leading padding bits in int,
again very common but not required.
> can of course simplify this into only two bytes if you like, it's just
> what I had floating around on my disk. Depends on what you're using it
> for, because then you can't see if it's a 'middle-endian' cpu (on a
> PDP-11 it should print '3412', but those are rare anyway.
Only if you make it 'long'; PDP-11 'int' was 16 bits (2 bytes of 8).
- David.Thompson1 at worldnet.att.net