Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>> +#if defined(__BYTE_ORDER) && defined(__BIG_ENDIAN)
>>> +/*
>>> + * Should detect Big Endian under glibc.git since 14245eb70e ("entered
>>> + * into RCS", 1992-11-25). Defined in <endian.h> which will have been
>>> + * brought in by standard headers. See glibc.git and
>>> + * https://sourceforge.net/p/predef/wiki/Endianness/
>>> + */
>>> +#if __BYTE_ORDER == __BIG_ENDIAN
>>> #define SHA1DC_BIGENDIAN
>>> #endif
>>
>> Note that this part of the file considers it a valid way for a
>> platform to define a constant BIG_ENDIAN that can be compared to
>> BYTE_ORDER to determine the endianness, implying that such a scheme
>> would also define LITTLE_ENDIAN and a port of such a platform to a
>> little endian box will still _define_ the constant BIG_ENDIAN; it
>> aill have BYTE_ORDER defined to the same value as LITTLE_ENDIAN,
>> though.
>
> This may fail if we have some non-glibc platform that's defining
> __BYTE_ORDER and __BIG_ENDIAN, but if it's glibc then __BIG_ENDIAN will
> always be defined, even on little-endian platforms.
Yes, that is exactly the point of my comment. We want to be
prepared to see a platform that is not big endian to define
BIG_ENDIAN (with some underscore).
>>> +#else /* Not under GCC-alike or glibc or <processor whitelist> or <processor blacklist> */
>>> +
>>> +#ifdef _BIG_ENDIAN
>>> +/*
>>> + * Solaris / illumos defines either _LITTLE_ENDIAN or _BIG_ENDIAN in
>>> + * <sys/isa_defs.h>.
>>> + */
>>> +#define SHA1DC_BIGENDIAN
>>
>> This makes readers of this patch wonder why we assume platforms
>> won't define _LITTLE_ENDIAN and _BIG_ENDIAN at the same time, just
>> like we saw in the section with __BIG_ENDIAN above.
>
> At least on Solaris if we get this far that won't be the case.
Yes, but the remainder of world is not all Solaris.
