Re: Endianness

3 views
Skip to first unread message

Eric Sosman

unread,
Jun 22, 2005, 2:01:03 PM6/22/05
to

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
represented.

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
system's documentation.

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
machines.

The worst way of all is to imagine that you know the answer
without needing to ask.

--
Eric....@sun.com

bush

unread,
Jun 22, 2005, 1:13:23 PM6/22/05
to

Tydr Schnubbis

unread,
Jun 22, 2005, 3:14:40 PM6/22/05
to
#include <stdio.h>

int main()
{
int n = 0x04030201;
char *s = (char *)&n;

printf("%d%d%d%d\n", s[0], s[1], s[2], s[3]);

return 0;
}

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.

Tydr Schnubbis

unread,
Jun 22, 2005, 3:10:14 PM6/22/05
to
#include <stdio.h>

int main()
{
int n = 0x04030201;

char *s = (void *)&n;

Felix Rawlings

unread,
Jun 22, 2005, 9:14:09 PM6/22/05
to
On Wed, 22 Jun 2005 14:01:03 -0400, Eric Sosman wrote:

>
>
> 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
> represented.

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.


Eric Sosman

unread,
Jun 22, 2005, 10:25:09 PM6/22/05
to

1) I did mention that the strait and narrow way is not
always practical.

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.

--
Eric Sosman
eso...@acm-dot-org.invalid

Lawrence Kirby

unread,
Jun 23, 2005, 7:25:05 AM6/23/05
to

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.

Lawrence


Dave Thompson

unread,
Jul 4, 2005, 1:38:38 AM7/4/05
to
On Wed, 22 Jun 2005 19:14:40 GMT, Tydr Schnubbis <fa...@address.dude>
wrote:
<snip>

> int n = 0x04030201;
> char *s = (char *)&n;
>
> printf("%d%d%d%d\n", s[0], s[1], s[2], s[3]);
>
> return 0;
> }
>
> 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

(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

Reply all
Reply to author
Forward
0 new messages