From: Michael Felt <aixtools@felt.demon.nl>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org, Dan Shumow <shumow@gmail.com>,
Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Subject: Re: Is detecting endianness at compile-time unworkable?
Date: Tue, 31 Jul 2018 14:32:42 +0200 [thread overview]
Message-ID: <73cd8ad3-f093-b82e-9726-b27f2214629d@felt.demon.nl> (raw)
In-Reply-To: <87wotdt649.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> The reason we're in this hole is because we use this
> sha1collisiondetection library to do SHA-1, and the reason we have
> issues with it specifically (not OpenSSL et al) is because its only
> method of detecting endianness is at compile time.
When using gcc (no xlc available for Linux on Power)
POWER6 (Big Endian by definition)
root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep -i end
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __BIG_ENDIAN__ 1
#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define _BIG_ENDIAN 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
SLES12 on POWER8
suse12test:~ # gcc -dM -E - < /dev/null | grep -i end
#define __ORDER_LITTLE_ENDIAN__ 1234
#define _LITTLE_ENDIAN 1
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
*So, for compile time tests, when gcc is the compiler it seems the
following defines are available**
**__BIG_ENDIAN__, _BIG_ENDIAN, __LITTLE__ENDIAN__, _LITTLE_ENDIAN**
**or something based on the value of __BYTE_ORDER__*
I'll see if I can find something similar for xlc, but will only be able
to test xlc on AIX.
>
> This didn't use to be the case, it was changed in this commit:
> https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672
>
> Dan Shumow: Since the commit message doesn't say why, can you elaborate
> a bit on why this was done, i.e. is determining this at runtime harmful
> for performance? If not, perhaps it would be best to bring this back, at
> least as an option.
[-- Attachment #2: Type: text/html, Size: 2629 bytes --]
next prev parent reply other threads:[~2018-07-31 12:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-29 16:44 git broken for AIX somewhere between 2.13.2 and 2.13.3 Michael
2018-07-29 18:10 ` brian m. carlson
2018-07-29 19:46 ` Michael
2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason
2018-07-29 21:40 ` Andreas Schwab
2018-07-30 6:22 ` Michael
[not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl>
[not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net>
2018-07-29 19:48 ` Michael
2018-07-29 20:06 ` brian m. carlson
2018-07-29 20:50 ` Michael
2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason
2018-07-30 14:54 ` Junio C Hamano
2018-07-30 18:32 ` Junio C Hamano
2018-07-30 18:39 ` Daniel Shumow
2018-07-31 10:06 ` Michael Felt
2018-08-01 1:35 ` Eric Wong
2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason
2018-07-31 10:39 ` Michael Felt
2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason
2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2018-08-02 21:29 ` Michael Felt (aixtools)
2018-08-02 21:32 ` Stefan Beller
2018-07-31 12:32 ` Michael Felt [this message]
2018-07-31 14:01 ` Is detecting endianness at compile-time unworkable? Michael Felt
2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason
2018-07-31 20:06 ` Michael
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=73cd8ad3-f093-b82e-9726-b27f2214629d@felt.demon.nl \
--to=aixtools@felt.demon.nl \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=shumow@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).