Re: [PATCH 3/3] compat/bswap.h: Detect endianness from XL C compiler macros

From: Jeff King <peff@peff.net>
Date: Oct 27, 2014, 05:12 UTC
Message-ID: <20141027051225.GB2996@peff.net>
In-Reply-To: <CAEvUa7mcJhYwivQjbWnVEXj_+fhCS+2edCFWjmEotOXKahQdww@mail.gmail.com>

On Sun, Oct 26, 2014 at 04:04:01PM -0400, David Michael wrote:

Show 13 quoted lines

> I'm not 100% sure if __THW_LITTLE_ENDIAN__ will ever be defined, so
> I'd be okay with dropping those references completely.  There is a
> recent version of the compiler for little endian Linux distributions,
> but I haven't found the documentation for it.  (The product
> documentation still seems to only refer to the big endian Linux
> version.)  The compiler's macro may be redundant in this case anyway,
> since Linux systems should have <bits/endian.h> supplying that
> information.
> 
> I only used both macros for completeness; the __THW_BIG_ENDIAN__ macro
> (defined to 1 on z/OS and AIX) is what I actually needed here.  z/OS
> doesn't seem to have any other compile-time byte order indicator,
> short of testing for the OS itself.

Thanks for the explanation.

> Would you prefer the two-line patch to only test for the big endian
> macro,

I think that's OK, as long as the #else case barfs as it does now (i.e., doesn't silently choose little-endian).

> or maybe just test for __MVS__ to look at the OS?

If the OS's you're testing on all provide a big-endian marker like __THW_BIG_ENDIAN__, that seems preferable to me to use, as it's more explicit. We can deal with similar little-endian systems if and when somebody sees one in the wild (and your explanation that it would probably hit the Linux <bits/endian.h> check first makes sense to me).

-Peff