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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> Update sha1dc from my PR #36[1] which'll hopefully be integrated by
>> upstream soon.
>
> Please be careful about the title of the patch.  "log --oneline"
> does not even let you tell your readers who calls this as "my"
> change, and readers would be clueless what PR #36 is.  Something
> like
>
>     sha1dc: correct endian detection for Solaris
>
> may give us more relevant information in the oneline output.

Will fix. Can you integrate it as-is into pu anyway? I'm going to need
to re-submit it regardless once we get some testing on it & upstream
merges the PR, but having it in Travis et al in the meantime would be
great.

>> @@ -23,6 +23,13 @@
>>  #include "sha1.h"
>>  #include "ubc_check.h"
>>
>> +#if (defined(__amd64__) || defined(__amd64) || defined(__x86_64__) || defined(__x86_64) || \
>> +     defined(i386) || defined(__i386) || defined(__i386__) || defined(__i486__)  || \
>> +     defined(__i586__) || defined(__i686__) || defined(_M_IX86) || defined(__X86__) || \
>> +     defined(_X86_) || defined(__THW_INTEL__) || defined(__I86__) || defined(__INTEL__) || \
>> +     defined(__386) || defined(_M_X64) || defined(_M_AMD64))
>> +#define SHA1DC_ON_INTEL_LIKE_PROCESSOR
>> +#endif
>
> It is good that you made this orthogonal to the rest.
>
>> +#else /* Not under GCC-alike */
>>
>> +#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.

>> +#if (defined(__ARMEB__) || defined(__THUMBEB__) || defined(__AARCH64EB__) || \
>>       defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || \
>>       defined(__sparc))
>> +/*
>> + * Should define Big Endian for a whitelist of known processors. See
>> + * https://sourceforge.net/p/predef/wiki/Endianness/ and
>> + * http://www.oracle.com/technetwork/server-storage/solaris/portingtosolaris-138514.html
>> + */
>>  #define SHA1DC_BIGENDIAN
>
> These look sensible.
>
>> +#else /* Not under GCC-alike or glibc or <processor whitelist> */
>> +
>> +#if defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR)
>> +/*
>> + * As a last resort before we fall back on _BIG_ENDIAN or whatever
>> + * else we're not 100% sure about below, we blacklist specific
>> + * processors here. We could add more, see
>> + * e.g. https://wiki.debian.org/ArchitectureSpecificsMemo
>> + */
>> +#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.

> Thanks, but this is starting to feel like watching a whack-a-mole
> played while blindfolded.

Yeah for sure, I don't have access to solaris/cygwin or other obscure
platforms myself.

I do think this is fundimentally a better approach though since we first
check exactly what we know GCC / clang have, then glibc etc.

But yeah, by the time we're detecting Solaris I'm somewhat shooting
blind.