Re: AC_C_BIGENDIAN: grep'ing an object file

[Ralf Corsepius]

Am 12 Aug 2001 14:00:00 +0200 schrieb Alexandre Duret-Lutz:
> >>> "Akim" == Akim Demaille <address@hidden> writes:
> 
> [...]
> 
>  Akim> I'd be very happy if your completion of the documentation could also
>  Akim> explain that it most situations, detecting the endianness at runtime
>  Akim> is a preferred solution, 
> 
> I'm sorry, none of the 3 patches I've sent do this.  The reason
> is that this would requires some arguments I don't have :)
> 
> IMHO the prefered solution is to NOT rely on byte ordering at
> all.  But when you start to rely on it, I can only come up to
> examples where either speed is involved and you can't afford
> doing some byte-sex-dispatch in you routines, either you don't
> want to bloat your code with twin functions supporting each
> endianness because actually only half of them will be used.  (I
> remember I heard about a transexual system which could change
> it's byte ordering at run-time, and would therefore justify a
> run-time check, is that real or just a myth?)
No, it's not a myth. 

AFAIK, there are quite a few processors/architectures out there which
allow doing so. I know the Hitachi SH-family is able to do so, but AFAIK
there are more (mips, ppc ... ?). However, I've never seen any OS or
application exploiting this.

Furthermore, I would expect code which changes endianness at run-time to
do so in low-level routines, probably implemented in assembly code,
because using a compiler normally already implies using an implied
endianness and depending on it.

>From autoconf's perspective there is another problem lurking:
Users can easily change the compiler's endianness inbetween
configuration-time and make-time,
 
Eg. with sh-gcc-toolchains:
./configure -> checking for SH1-bigendian characteristics
CFLAGS=-ml ./make -> using SH1-little-endian

Anyway, IMHO, this is a general limitation of autoconf's working
principles (autoconf does not guarantee contradictency of FLAGS for
configuration and make-time), therefore I would count this as a "user's
fault" and would not blame autoconf.

Ralf