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
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
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 was
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
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
if
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 not is
[Re-send to include the list. Meant to hit reply all, not just reply.]
On Jan 30, 2014, at 3:45 PM, Jeff King p...@peff.net 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
On Thu, Jan 30, 2014 at 4:50 PM, Jeff King p...@peff.net 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
8 matches
Mail list logo
