|
Home > Archive > Unix Programming > May 2005 > Determining endian?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Determining endian?
|
|
| Daniel Rudy 2005-05-12, 7:55 am |
| Hello,
In Unix, is there a standard way to automaticly determine what the
endian of the hardware platform is when compiling a program? There's
some software that I have that runs fine on the Intel platform, but it
has problems on the PowerPC (Macintosh) platform.
--
Daniel Rudy
Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.
| |
| Chris McDonald 2005-05-12, 7:55 am |
| Daniel Rudy <nospam@nospam.net> writes:
> In Unix, is there a standard way to automaticly determine what the
>endian of the hardware platform is when compiling a program? There's
>some software that I have that runs fine on the Intel platform, but it
>has problems on the PowerPC (Macintosh) platform.
#include <stdio.h>
#define p(s) printf(#s" endian\n")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
--
Chris,
| |
| Måns Rullgård 2005-05-12, 7:55 am |
| Daniel Rudy <nospam@nospam.net> writes:
> Hello,
>
> In Unix, is there a standard way to automaticly determine what the
> endian of the hardware platform is when compiling a program? There's
> some software that I have that runs fine on the Intel platform, but it
> has problems on the PowerPC (Macintosh) platform.
int test = 1;
int little_endian = *(char *)&test;
--
Måns Rullgård
mru@inprovide.com
| |
| Gordon Burditt 2005-05-12, 7:55 am |
| > In Unix, is there a standard way to automaticly determine what the
>endian of the hardware platform is when compiling a program? There's
>some software that I have that runs fine on the Intel platform, but it
>has problems on the PowerPC (Macintosh) platform.
There are plenty of ways for software to screw up besides endian
issues.
There's no standard way to represent the answer. Any method that
assumes that the answer is either "little" or "big" is doomed to
failure. "inner right endian", anyone?
Gordon L. Burditt
| |
| Daniel Rudy 2005-05-12, 7:56 am |
| At about the time of 5/12/2005 3:36 AM, Gordon Burditt stated the following:
>
>
> There are plenty of ways for software to screw up besides endian
> issues.
True, but I try to keep that to a minimum. ;-)
> There's no standard way to represent the answer. Any method that
> assumes that the answer is either "little" or "big" is doomed to
> failure. "inner right endian", anyone?
>
> Gordon L. Burditt
I though it could only be little or big. What is "inner right endian"?
--
Daniel Rudy
Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.
| |
| Måns Rullgård 2005-05-12, 7:56 am |
| Daniel Rudy <nospam@nospam.net> writes:
>
> True, but I try to keep that to a minimum. ;-)
>
>
> I though it could only be little or big. What is "inner right endian"?
There are theoretically 24 ways of storing 32-bit data. At least
three of these have been used at one time or another. Numbering the
bytes starting at the LSB, we have:
1234 little endian
4321 big endian
3412 pdp endian
Of the rest, only 2143 seems likely to be found.
I'll have to admit I have no idea what inner right endian refers to.
--
Måns Rullgård
mru@inprovide.com
| |
| Pascal Bourguignon 2005-05-12, 5:52 pm |
| gordonb.hwf59@burditt.org (Gordon Burditt) writes:
>
> There are plenty of ways for software to screw up besides endian
> issues.
>
> There's no standard way to represent the answer. Any method that
> assumes that the answer is either "little" or "big" is doomed to
> failure. "inner right endian", anyone?
But it still is possible to convert between normal order (big endian,
eg. network byte order), and any endian with:
#include <stdio.h>
typedef union {
long l;
char index[4];
} converter_t;
long convert_order(long input)
{
converter_t x,i,o;
int k;
i.l=input;
x.l=0x00010203;
for(k=0;k<4;k++){o.index[k]=i.index[x.index[k]];}
return(o.l);
}
int main(void){
long native_order=123456789;
long normal_order=convert_order(native_order)
;
long back_to_native_order=convert_order(norma
l_order);
printf("%08x %08x %08x\n" ,native_order,normal_order,back_to_nativ
e_order);
return(0);
}
make native-order ; ./native-order
cc native-order.c -o native-order
075bcd15 15cd5b07 075bcd15
Try it on your favorite random endian architecture!
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
| |
| James Antill 2005-05-12, 5:52 pm |
| On Thu, 12 May 2005 10:17:44 +0000, Daniel Rudy wrote:
> Hello,
>
> In Unix, is there a standard way to automaticly determine what the
> endian of the hardware platform is when compiling a program? There's
> some software that I have that runs fine on the Intel platform, but it
> has problems on the PowerPC (Macintosh) platform.
It isn't in SuS3, but it's a common BSD extension.
#include <endian.h>
#if BYTE_ORDER == LITTLE_ENDIAN
#if BYTE_ORDER == BIG_ENDIAN
#if BYTE_ORDER == PDP_ENDIAN
--
James Antill -- james@and.org
http://www.and.org/vstr/httpd
| |
| Bjorn Reese 2005-05-12, 5:52 pm |
| Daniel Rudy wrote:
> In Unix, is there a standard way to automaticly determine what the
> endian of the hardware platform is when compiling a program? There's
> some software that I have that runs fine on the Intel platform, but it
> has problems on the PowerPC (Macintosh) platform.
You can write your software to be endian-agnostic. For an example see
http://groups.google.dk/groups?selm...k&output=gplain
--
mail1dotstofanetdotdk
| |
| David Schwartz 2005-05-12, 5:52 pm |
|
"James Antill" <james-netnews@and.org> wrote in message
news:pan.2005.05.12.15.40.13.128150@and.org...
> It isn't in SuS3, but it's a common BSD extension.
>
> #include <endian.h>
>
> #if BYTE_ORDER == LITTLE_ENDIAN
> #if BYTE_ORDER == BIG_ENDIAN
> #if BYTE_ORDER == PDP_ENDIAN
There are similar extensions on every platform I've ever used. Unless
you really need to support machines where the edianness can be set at boot
time (yes, they exist), you should just find the appropriate headers to
trigger preprocessor tests.
Of course, it's much better to write endian-agnostic code. But sometimes
you can 'ifdef' out a chunk of code if you just happen to be on a machine
with the right endian-ness. I recommend using endian awareness only as an
optimization and not making code rely on it.
DS
|
|
|
|
|