On Thu, Jan 30, 2014 at 4:50 PM, Jeff King wrote:
> I think we could do this with something like the patch below, which
> checks two things:
>
> 1. When we expand the ewah, it has the same number of bits we claimed
> in the on-disk header.
>
> 2. The ewah header matches the number of obje
[Re-send to include the list. Meant to hit reply all, not just reply.]
> On Jan 30, 2014, at 3:45 PM, Jeff King wrote:
>
> I do find the failure mode interesting. The endian-swapping code kicked
> in when it did not, meaning your are on a big-endian system. Is this on
> an ancient PPC Mac? Or is
On Thu, Jan 30, 2014 at 02:12:05PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I do find the failure mode interesting. The endian-swapping code kicked
> > in when it did not
>
> Odd --- wouldn't the #if condition expand to '0 != 0'?
I had the same thought. The "kicked in when it did
On Thu, Jan 30, 2014 at 02:02:33PM -0800, Jonathan Nieder wrote:
> In an ideal world I would prefer to just rely on ntohll when it's
> decent (meaning that the '#if __BYTE_ORDER != __BIG_ENDIAN' block
> could be written as
>
> if (ntohll(1) != 1) {
> ...
> }
>
> or
>
>
Hi,
Jeff King wrote:
> I do find the failure mode interesting. The endian-swapping code kicked
> in when it did not
Odd --- wouldn't the #if condition expand to '0 != 0'?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
Hi,
Brian Gernhardt wrote:
> a201c20 (ewah: support platforms that require aligned reads) added a
> reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However,
> these macros are spelled without the leading __ on some platforms (OS
> X at least). In this case, the endian-swapping code
On Thu, Jan 30, 2014 at 03:45:38PM -0500, Jeff King wrote:
> Either way, we should perhaps be more careful in the bitmap code, too,
> that the values we get are sensible. It's better to die("your bitmap is
> broken") than to read off the end of the array. I can't seem to trigger
> the same failure
On Thu, Jan 30, 2014 at 02:55:41PM -0500, Brian Gernhardt wrote:
> a201c20 (ewah: support platforms that require aligned reads) added a
> reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However,
> these macros are spelled without the leading __ on some platforms (OS
> X at least). In
a201c20 (ewah: support platforms that require aligned reads) added a
reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However,
these macros are spelled without the leading __ on some platforms (OS
X at least). In this case, the endian-swapping code was added even
when unnecessary, whic
9 matches
Mail list logo
