Re: [PATCH] Ensure __BYTE_ORDER is always set
From: Brian Gernhardt <hidden>
Date: 2016-06-15 22:59:47
[Re-send to include the list. Meant to hit reply all, not just reply.]
On Jan 30, 2014, at 3:45 PM, Jeff King [off-list ref] 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 the problem that the code did not kick in when it should?
Erm. I was perhaps writing my analysis too quickly. I was running on a x86_64 Mac, so it wasn't included when it was supposed to be. Or whichever you said that I didn't. ;-)
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 mode, though. On my x86 system, turning off the
endian-swap (i.e., the opposite of what should happen) makes t5310 fail,
but it is because we end up trying to set the bit very far into a
dynamic bitfield, and die allocating memory.To be more specific, I hit an assertion failure at in ewah_iterator_next() (ewah/ewah_bitmap.c:355) when running `git rev-list --test-bitmap HEAD` (and others if I don't have it die immediately). That seems to me that there is a check to ensure it doesn't run off the end. Perhaps you have assertions disabled so hit an error somewhere else? ~~ Brian Gernhardt