From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] strbuf: use st_add3() in strbuf_grow()
Date: Thu, 14 May 2026 22:13:19 +0200 [thread overview]
Message-ID: <0c3b4e94-b56c-4c92-a4d8-0e4364f1257b@web.de> (raw)
In-Reply-To: <xmqqo6ihg690.fsf@gitster.g>
On 5/14/26 9:07 PM, Junio C Hamano wrote:
> René Scharfe <l.s.r@web.de> writes:
>
>> Simplify the code by calling st_add3() to do overflow checks instead of
>> open-coding it. This changes the error message to include the offending
>> summands, which can be helpful when tracking down the cause.
>>
>> Signed-off-by: René Scharfe <l.s.r@web.de>
>> ---
>> strbuf.c | 5 +----
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/strbuf.c b/strbuf.c
>> index 3e04addc22..bb04d3910e 100644
>> --- a/strbuf.c
>> +++ b/strbuf.c
>> @@ -106,12 +106,9 @@ void strbuf_attach(struct strbuf *sb, void *buf, size_t len, size_t alloc)
>> void strbuf_grow(struct strbuf *sb, size_t extra)
>> {
>> int new_buf = !sb->alloc;
>> - if (unsigned_add_overflows(extra, 1) ||
>> - unsigned_add_overflows(sb->len, extra + 1))
>> - die("you want to use way too much memory");
>> if (new_buf)
>> sb->buf = NULL;
>> - ALLOC_GROW(sb->buf, sb->len + extra + 1, sb->alloc);
>> + ALLOC_GROW(sb->buf, st_add3(sb->len, extra, 1), sb->alloc);
>
> ALLOC_GROW() being a macro that references its second argument three
> times, doesn't this rewrite rely on the compiler being clever enough
> to notice that checking for the same overflow three times is
> pointless and does it only once? I guess the original has the same
> issue already, so this may not be so bad but it makes me feel a bit
> queasy.
As long as it has no side-effect (as is the case for addition) and we
keep compiler optimization enabled we should be fine.
I guess the reason for having multiple references as opposed to
loading the value once into a private variable is to support arbitrary
types. In the end it needs to fit into a size_t, though. Something
like this could bring the reference count down to one:
--- 8< ---
diff --git a/git-compat-util.h b/git-compat-util.h
index ae1bdc90a4..ca89cfb0b3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -812,6 +812,15 @@ static inline void move_array(void *dst, const void *src, size_t n, size_t size)
#define alloc_nr(x) (((x)+16)*3/2)
+static inline bool st_alloc_nr(size_t nr, size_t alloc, size_t *out)
+{
+ if (nr > alloc) {
+ *out = alloc_nr(alloc) < nr ? nr : alloc_nr(alloc);
+ return true;
+ }
+ return false;
+}
+
/**
* Dynamically growing an array using realloc() is error prone and boring.
*
@@ -857,12 +866,10 @@ static inline void move_array(void *dst, const void *src, size_t n, size_t size)
*/
#define ALLOC_GROW(x, nr, alloc) \
do { \
- if ((nr) > alloc) { \
- if (alloc_nr(alloc) < (nr)) \
- alloc = (nr); \
- else \
- alloc = alloc_nr(alloc); \
- REALLOC_ARRAY(x, alloc); \
+ size_t alloc_grow_new_alloc_; \
+ if (st_alloc_nr((nr), (alloc), &alloc_grow_new_alloc_)) { \
+ alloc = alloc_grow_new_alloc_; \
+ REALLOC_ARRAY(x, alloc_grow_new_alloc_); \
} \
} while (0)
--- >8 ---
Hmm, alloc_nr() doesn't do any overflow checking. It should, though,
shouldn't it?
René
next prev parent reply other threads:[~2026-05-14 20:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 15:11 [PATCH 1/2] strbuf: use st_add3() in strbuf_grow() René Scharfe
2026-05-14 15:13 ` [PATCH 2/2] use __builtin_add_overflow() in st_add() with Clang René Scharfe
2026-05-14 19:12 ` Junio C Hamano
2026-05-14 20:17 ` René Scharfe
2026-05-15 16:49 ` René Scharfe
2026-05-15 4:40 ` Jeff King
2026-05-15 14:36 ` René Scharfe
2026-05-15 16:53 ` Jeff King
2026-05-14 19:07 ` [PATCH 1/2] strbuf: use st_add3() in strbuf_grow() Junio C Hamano
2026-05-14 20:13 ` René Scharfe [this message]
2026-05-15 4:36 ` Jeff King
2026-05-15 14:30 ` René Scharfe
2026-05-15 16:50 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c3b4e94-b56c-4c92-a4d8-0e4364f1257b@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox