This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Robust detection of endianness at compile time.
- From: Andrew Haley <aph-gcc at littlepinkcloud dot COM>
- To: "Lee Rhodes" <lee at rhoba dot com>
- Cc: <gcc-help at gcc dot gnu dot org>
- Date: Mon, 30 Jul 2007 18:50:06 +0100
- Subject: Re: Robust detection of endianness at compile time.
- References: <001401c7d2cc$f9e5b250$0701a8c0@lee8075b>
Lee Rhodes writes:
> > "Andrew Haley" wrote:
> >
> > Yes, there is.
> >
> > Endianness, like hundreds of other environment quersies needed at
> > compile time, is handled by GNU Autoconf. There's nothing special
> > about endianness: it's just another property of the environment you're
> > compiling for.
>
> Thanks for pointing me to Autoconf. I haven't used Autoconf, but I
> will now have to study it. Nonetheless, the Macro AC_C_BIGENDIAN
> appears to only check for the big endian case, the tacit assumption
> being that if it ain't big it must be little. But what about the
> PDP/ARM case? Or is it's weird layout no longer supported by GCC?
AC_C_BIGENDIAN is for integers. As far as I am aware the PDP/ARM
"middle-endian" problem only applies to floating-point words, and the
situation for those is far more complex than mere endianness. Not
every platform supports the IEEE-754 format, and picking apart other
formats requires special-case programming. Happily, this isn't a
problem that most people have to solve.
I mostly agree with Nick, by the way: in most cases it's best to use
standard portable code internally and only do endian conversions at
I/O boundaries. This is the approach taken by the htonl() family of
functions. It's very rare that anyone really needs to do anything
that needs to know the endianness of a machine. (Of course, I don't
know what problem you're trying to solve, so I'm not saying that *you*
don't need to do something that needs it.)
Andrew.