Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2018, 16:41 UTC
Message-ID: <xmqq1sd82e9h.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <f6931351-df79-cb76-ee29-c57472a6a201@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 9 quoted lines

> On 6/14/2018 11:44 PM, Jeff King wrote:
>> The return value of ewah_read_mmap() is now an ssize_t,
>> since we could (in theory) process up to 32GB of data. This
>> would never happen in practice, but a corrupt or malicious
>> .bitmap or index file could convince us to do so.
>
> Aside: Why a 32GB limit? Usually I see 32-bit issues limiting by 2
> (signed) or 4 GB (unsigned). Is there something specifically in the
> bitmap format that stops at this size?

The proposed log message for 1/3 has this bit

  - check the size for integer overflow (this should be
    impossible on 64-bit, as the size is given as a 32-bit
    count of 8-byte words, but is possible on a 32-bit
    system)

4 Giga 8-byte words makes 32 Giga bytes, I'd guess.