Re: Git v2.13.1 SHA1 very broken
- From
- Morten Welinder <mwelinder@gmail.com>
- Date
- Jun 6, 2017, 12:49 UTC
- Message-ID
- <CANv4PN=G82J86eaPkvy8ZaXZGSnHoJRuKFeLcF34aX6_9Y9fcg@mail.gmail.com>
- In-Reply-To
- <xmqqmv9l8h5z.fsf@gitster.mtv.corp.google.com>
One could have configure ask some existing dependency that has already determined the byte order. For example:
# perl -e 'use Config; $o=$Config{byteorder}; print(($o=~/^1234/ ? "little" : ($o=~/4321$/ ? "big" : "weird")), "\n");' little
Good: less #ifdef soup; bad: not so great for cross-compiling.
(That's the integer byte order. The floating-point byte order can be different; hopefully git doesn't care.)
Morten
On Tue, Jun 6, 2017 at 7:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> Adam Dinwoodie <adam@dinwoodie.org> writes: > >> Digging briefly into the endianness detection, it appears Cygwin has >> both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by >> assuming it's in a little endian environment and switching to big endian >> if it detects any of the defines that indicate such, and a010391 adds >> _BIG_ENDIAN to the set of defines that indicate big endianness. > > I suspect that the upstream has already fixed this one to cope with > FreeBSD. My preference is that we do another import on top of the > ab/sha1dc-maint topic, below the commit on ab/sha1dc that adds the > upstream as a submodule. >