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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>>> +#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.
>
> By the way, I wonder why this didn't catch the sparc running
> Solaris.  What does Michael's system use to let the software know
> that it is targetted for a Sparc, if not __sparc?

Because in the current code is, abbreviated:

    #if (defined(_BYTE_ORDER) || defined(__BYTE_ORDER) || defined(__BYTE_ORDER__))
    #if /* byte order is bendian */
    #define SHA1DC_BIGENDIAN
    #endif
    #else
    #if /*some processor tests/* || defined(__sparc))
    #define SHA1DC_BIGENDIAN
    #endif

And since Solaris defines _BYTE_ORDER we never get to checking __sparc,
and in fact the "/* byte order is bendian */" test errors out.

This is fixed by my patch, where we first check gcc settings, then
glibc, then processors, and finally _BYTE_ORDER (but as discussed that
last bit could be adjusted to sun && _BYTE_ORDER, if we can find what
"sun" is.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux