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.

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,

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

>	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

At about the time of 5/12/2005 3:36 AM, Gordon Burditt stated the following:

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

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.

Daniel Rudy <nospam@nospam.net> writes:

>> 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?
>
> 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

gordonb.hwf59@burditt.org (Gordon Burditt) 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.
>
> 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(normal_order);

printf("%08x %08x %08x\n",native_order,normal_order,back_to_native_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.

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

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=3E86E006.F55EE981%40mail1.stofanet.dk&output=gplain

-- 
mail1dotstofanetdotdk

"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