summaryrefslogtreecommitdiff
path: root/tag.h
diff options
context:
space:
mode:
authorLibravatar Taylor Blau <me@ttaylorr.com>2020-12-08 17:03:14 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-12-08 14:48:15 -0800
commit3b1ca60f8f317b483c8c1805ab500ff2b014cbec (patch)
tree1d34abf5bce2e429ff604b1f98e66ce707bf6944 /tag.h
parentFifth batch (diff)
downloadtgif-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