Re: Robust detection of endianness at compile time.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Lee Rhodes" <lee@xxxxxxxxx> wrote:
>
> There doesn't appear to be a simple and robust (i.e., cross-platform) way of
> determining the endianness of the underlying platform at compile-time.

No, there isn't.  And it may not even be possible!  With co-processors,
which were common with early IBM PCs and are making a slight comeback,
the endianness of (typically) floating-point may vary with every
execution.  Yes, using the same binary.  Most language standards
permit that, and C is one of the few to forbid it even for integers
(it allows it for floating-point).

> 1.  Since the compiler clearly HAS to know endianess why isn't there a
> simple, robust way to test for it on all platforms without depending on a
> header?

Actually, it doesn't.  It has to do so only for C integers.

> 2.  How reliable is the existance of <endian.h> across all platforms?

When I last looked (a decade ago), dire.  It is unlikely that the
situation has improved.  It exists, but is not reliable.

> 5.  Where is the documentation on how one should write cross-platform code
> wrt endianess using GCC?

Well, when I had to tackle this, I started off by using the 'modern'
approach of a compile-time switch.  I then hit the DEC MIPS systems,
and decided to do the job properly (i.e. using 1960s techniques).
The resulting code was FAR more general, FAR clearer and half the
length.  And no slower.  But you won't find those techniques
documented anywhere, except possibly in some VERY hard to obtain
programmers' notes.

In general, you need to know the endianness only when interfacing
with external entities or protocols with a defined endianness that
is not your native one.  The most general solution is that you
analyse the endianness at start-up, create a table, and convert
when you need to.  EVERYTHING except the conversion code works in
the native layout.

For the past 20 years, such conversion has come essentially for
free.  CPUs are not the bottleneck - memory is.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@xxxxxxxxx
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux