ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW()
authorTaylor Blau <redacted>
Tue, 8 Dec 2020 22:03:14 +0000 (17:03 -0500)
committerJunio C Hamano <redacted>
Tue, 8 Dec 2020 22:48:15 +0000 (14:48 -0800)
commit3b1ca60f8f317b483c8c1805ab500ff2b014cbec
tree1d34abf5bce2e429ff604b1f98e66ce707bf6944
parente31aba42fb12bdeb0f850829e008e1e3f43af500
ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW()

'ewah/ewah_bitmap.c:buffer_grow()' is responsible for growing the buffer
used to store the bits of an EWAH bitmap. It is essentially doing the
same task as the 'ALLOC_GROW()' macro, so use that instead.

This simplifies the callers of 'buffer_grow()', who no longer have to
ask for a specific size, but rather specify how much of the buffer they
need. They also no longer need to guard 'buffer_grow()' behind an if
statement, since 'ALLOC_GROW()' (and, by extension, 'buffer_grow()') is
a noop if the buffer is already large enough.

But, the most significant change is that this fixes a bug when calling
buffer_grow() with both 'alloc_size' and 'new_size' set to 1. In this
case, truncating integer math will leave the new size set to 1, causing
the buffer to never grow.

Instead, let alloc_nr() handle this, which asks for '(new_size + 16) * 3
/ 2' instead of 'new_size * 3 / 2'.

Signed-off-by: Taylor Blau <redacted>
Signed-off-by: Junio C Hamano <redacted>
ewah/ewah_bitmap.c
git clone https://git.99rst.org/PROJECT