Re: pack bitmap woes on Windows

[Erik Faye-Lund <kusmabite@gmail.com>]

On Wed, Feb 12, 2014 at 3:09 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Wed, Feb 12, 2014 at 8:23 PM, David Kastrup <dak@gnu.org> wrote:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Am 2/12/2014 13:55, schrieb David Kastrup:
>>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>>>
>>>>> Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
>>>>> the following symptoms. I haven't followed the topic. Have there been
>>>>> patches floating that addressed the problem in one way or another?
>>>>>
>>>>> (gdb) run
>>>>> Starting program: D:\Src\mingw-git\t\trash
>>>>> directory.t5310-pack-bitmaps/..\..\git.exe rev-list --test-bitmap
>>>>> HEAD
>>>>> [New thread 3528.0x8d4]
>>>>> Bitmap v1 test (20 entries loaded)
>>>>> Found bitmap for 537ea4d3eb79c95f602873b1167c480006d2ac2d. 64 bits
>>>>> / 15873b36 checksum
>>>>
>>>> Does reverting a201c20b41a2f0725977bcb89a2a66135d776ba2 help?
>>>
>>> YES! t5310 passes after reverting this commit.
>>
>> Oh.  I just looked through the backtrace until finding a routine
>> reasonably related with the regtest and checked for the last commit
>> changing it, then posted my question.
>>
>> Then I looked through the diff of the patch and considered it
>> unconspicuous.  So I commenced reading through earlier commits.
>>
>> I actually don't have a good idea what might be wrong here.  The code is
>> somewhat distasteful as it basically uses eword_t and uint64_t
>> interchangeably, but then this does match its current definition.
>
> Perhaps __BYTE_ORDER or __BIG_ENDIAN is misdefined and the ntohll() is skipped?

That is indeed the case.