diff options
author | Taylor Blau <me@ttaylorr.com> | 2020-12-08 17:03:14 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-12-08 14:48:15 -0800 |
commit | 3b1ca60f8f317b483c8c1805ab500ff2b014cbec (patch) | |
tree | 1d34abf5bce2e429ff604b1f98e66ce707bf6944 /tag.h | |
parent | Fifth batch (diff) | |
download | tgif-3b1ca60f8f317b483c8c1805ab500ff2b014cbec.tar.xz |
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 <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'tag.h')
0 files changed, 0 insertions, 0 deletions