This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Robust detection of endianness at compile time.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]