Re: Robust detection of endianness at compile time.

[Nick Maclaren <nmm1 at cus dot cam dot ac dot uk>]

Brian Dessent <brian@dessent.net> wrote:
>
> Standard C header files in /usr/include such as endian.h are part of the
> libc.  They are not part of the compiler.  So no, they are not generated
> during installation of gcc, they are part of libc and installed when
> libc was installed.

Which is a mistake.  Not gcc's mistake, but still a mistake.

Headers such as limits.h, stdarg.h, setjmp.h and (in C99) fenv.h and
float.h have one foot in the library and one in the compiler.  You
can't compile code with one set and use it with another, even on
the same system and with compatible calling conventions.  Endian.h
is another, on any system that might support a coprocessor with
different conventions.

The mistake is that the C standard does not have a clean separation,
despite the fact that it has a 'compiler/library' distinction (the
hosted versus freestanding one).

> They are just regular ordinary #defines in a header file, which by
> definition means they are not built-in.  ...

Grrk.  See the above.  And take a look at FLT_ROUNDS for an apparently
simple symbol that is quite horribly entangled between the preprocessor,
compiler and library.

> As I said already, autoconf.

Well, those of us who write code that is intended to be portable
to systems that we haven't heard of, and are based on principles
that aren't currently used, don't use it.  I posted how to do that
in this case.

However, I agree that using endian.h is not a good solution.


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