From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Michael Kebe <michael.kebe@gmail.com>,
"Liam R . Howlett" <Liam.Howlett@Oracle.com>,
Adam Dinwoodie <adam@dinwoodie.org>,
Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH 1/3] sha1dc: update from my PR #36
Date: Tue, 27 Jun 2017 21:35:09 +0200 [thread overview]
Message-ID: <87r2y5jkb6.fsf@gmail.com> (raw)
In-Reply-To: <xmqq7ezx1c31.fsf@gitster.mtv.corp.google.com>
On Tue, Jun 27 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> 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.
>
> Well, if Solaris defines _BYTE_ORDER, doesn't that mean they define
> two constants _BIG_ENDIAN and _LITTLE_ENDIAN to compare it with?
No, under gcc/clang & glibc you're expected to compare them. Under
Solaris it's just defined(_BIG_ENDIAN), but as explained in another
comment this whole thing actually turns out to be not needed, on Solaris
it's sufficient that we fall through and check __sparc.
> that is the case, I suspect that the change to make "comparison
> between __BYTE_ORDER and __BIG_ENDIAN for GCC only" is going in a
> wrong direction, as it wants to take the same approach as GCC, but
> just uses a slightly different symbol.
>
> I wonder if the approach like the following might be cleaner to
> extend as we find other oddball platforms.
>
> #undef __SHA1DC_BYTE_ORDER
> #if defined(_BYTE_ORDER)
> #define __SHA1DC_BYTE_ORDER _BYTE_ORDER
> #elif defined(__BYTE_ORDER)
> #define __SHA1DC_BYTE_ORDER __BYTE_ORDER
> #elif defined(__BYTE_ORDER__))
> #define __SHA1DC_BYTE_ORDER __BYTE_ORDER__
> #endif
>
> #ifdef __SHA1DC_BYTE_ORDER
> #undef __SHA1DC_BIG_ENDIAN
> /* do the same for variations of BIG_ENDIAN constant */
> #if defined(_BIG_ENDIAN)
> ...
> #endif
>
> #if __SHA1DC_BYTE_ORDER == __SHA1DC_BIG_ENDIAN
> #define SHA1DC_BIGENDIAN
> #endif
As explained above no, because some e.g. _BIG_ENDIAN don't have a value
at all.
But more generally we can't assume that we can just exhaustively search
for some ^_*BIG_ENDIAN_*$ macro and compare it with some
^_*BYTE_ORDER_*$ value and get an expected result.
> #else
> /*
> * as the platform does not use "compare BYTE-ORDER with
> * BIG_ENDIAN macro" strategy, defined-ness of BIG_ENDIAN
> * may be usable as a sign that it is a big-endian box.
> */
> #endif
next prev parent reply other threads:[~2017-06-27 19:35 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 7:32 Compile Error v2.13.2 on Solaris SPARC Michael Kebe
[not found] ` <87lgofcf7r.fsf@gmail.com>
2017-06-26 12:36 ` Michael Kebe
2017-06-26 12:47 ` Ævar Arnfjörð Bjarmason
2017-06-26 14:00 ` Michael Kebe
2017-06-26 18:31 ` Ævar Arnfjörð Bjarmason
2017-06-26 18:29 ` Liam R. Howlett
[not found] ` <87fuem7aw2.fsf@gmail.com>
2017-06-27 5:41 ` Michael Kebe
2017-06-27 6:28 ` Michael Kebe
2017-06-27 16:28 ` Liam R. Howlett
2017-06-27 17:38 ` Junio C Hamano
2017-06-27 18:29 ` Liam R. Howlett
2017-06-27 18:55 ` Ævar Arnfjörð Bjarmason
2017-06-27 17:59 ` Ævar Arnfjörð Bjarmason
2017-06-27 12:17 ` [PATCH 0/3] update sha1dc from PR #36 Ævar Arnfjörð Bjarmason
2017-06-27 18:37 ` Stefan Beller
2017-06-27 20:33 ` [PATCH v2 " Ævar Arnfjörð Bjarmason
2017-06-27 21:37 ` Junio C Hamano
2017-06-27 21:38 ` Junio C Hamano
2017-06-27 22:24 ` Ævar Arnfjörð Bjarmason
2017-06-28 21:42 ` Ævar Arnfjörð Bjarmason
2017-06-28 22:02 ` Junio C Hamano
2017-06-27 20:33 ` [PATCH v2 1/3] sha1dc: correct endian detection for Solaris (and others?) Ævar Arnfjörð Bjarmason
2017-06-27 20:33 ` [PATCH v2 2/3] sha1dc: optionally use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-06-27 20:33 ` [PATCH v2 3/3] sha1collisiondetection: automatically enable when submodule is populated Ævar Arnfjörð Bjarmason
2017-07-01 22:05 ` [PATCH v3 0/3] Update sha1dc from upstream Ævar Arnfjörð Bjarmason
2017-07-01 22:05 ` [PATCH v3 1/3] sha1dc: update " Ævar Arnfjörð Bjarmason
2017-07-01 22:05 ` [PATCH v3 2/3] sha1dc: optionally use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-07-03 17:11 ` Junio C Hamano
2017-07-03 20:29 ` Ævar Arnfjörð Bjarmason
2017-07-04 17:26 ` Junio C Hamano
2017-07-04 22:50 ` Ævar Arnfjörð Bjarmason
2017-07-05 0:36 ` Stefan Beller
2017-07-05 1:56 ` Junio C Hamano
2017-07-05 17:46 ` Stefan Beller
2017-07-05 18:03 ` Ævar Arnfjörð Bjarmason
2017-07-01 22:05 ` [PATCH v3 3/3] sha1collisiondetection: automatically enable when submodule is populated Ævar Arnfjörð Bjarmason
2017-06-27 12:17 ` [PATCH 1/3] sha1dc: update from my PR #36 Ævar Arnfjörð Bjarmason
2017-06-27 15:22 ` Junio C Hamano
2017-06-27 15:53 ` Junio C Hamano
2017-06-27 18:07 ` Ævar Arnfjörð Bjarmason
2017-06-27 15:55 ` Junio C Hamano
2017-06-27 16:31 ` Liam R. Howlett
2017-06-27 18:11 ` Ævar Arnfjörð Bjarmason
2017-06-27 19:10 ` Junio C Hamano
2017-06-27 19:33 ` Junio C Hamano
2017-06-27 19:35 ` Ævar Arnfjörð Bjarmason [this message]
2017-06-27 19:38 ` Junio C Hamano
2017-06-27 19:38 ` Liam R. Howlett
2017-06-27 19:48 ` Junio C Hamano
2017-06-27 18:06 ` Ævar Arnfjörð Bjarmason
2017-06-27 18:12 ` Junio C Hamano
2017-06-27 18:19 ` Ævar Arnfjörð Bjarmason
2017-06-27 20:17 ` Junio C Hamano
2017-06-27 18:23 ` Junio C Hamano
2017-06-27 18:52 ` Ævar Arnfjörð Bjarmason
2017-06-27 12:17 ` [PATCH 2/3] sha1dc: optionally use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-06-27 18:46 ` Stefan Beller
2017-06-27 18:56 ` Ævar Arnfjörð Bjarmason
2017-06-27 12:17 ` [PATCH 3/3] sha1collisiondetection: automatically enable when submodule is populated Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2y5jkb6.fsf@gmail.com \
--to=avarab@gmail.com \
--cc=Liam.Howlett@Oracle.com \
--cc=adam@dinwoodie.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=michael.kebe@gmail.com \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.