On Tue, Jun 27 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason <ava...@gmail.com> 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).
Indeed, but FWIW this is the very first test in v2.13.0, so this
specific logic has already seen quite a bit of testing/porting on
numerous systems without issues (except Solaris obviously), but we'll
hopefully fix that this time around.
>>>> +#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.
It actually turns out this isn't needed, since we can just check __sparc
and skip checking _BIG_ENDIAN, so no Solaris-specific code needed.
> Yes, but the remainder of world is not all Solaris.
Indeed, but either once we're this far in the checks we're past anything
that runs gcc/clang/glibc or <list of known bigendian processors>, which
is going to be a small list regardless.
Anyway, will fix.
