Re: [PATCH 1/3] sha1dc: update from my PR #36

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 27, 2017, 18:52 UTC
Message-ID: <87tw31jmau.fsf@gmail.com>
In-Reply-To: <xmqqk23x1e8h.fsf@gitster.mtv.corp.google.com>

On Tue, Jun 27 2017, Junio C. Hamano jotted:

Show 28 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@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.

Show 14 quoted lines

>>>> +#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.