From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, peff@peff.net, newren@gmail.com,
Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 3/6] wrapper: create safe_memory_limit_check()
Date: Mon, 21 Sep 2026 14:24:28 -0700 [thread overview]
Message-ID: <xmqqzexal2lv.fsf@gitster.g> (raw)
In-Reply-To: <3b3c67243d200a42aa105981b64228e2cbb35a6c.1789736540.git.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Fri, 18 Sep 2026 13:02:17 +0000")
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +static int safe_memory_limit_check(size_t size, int verbose)
> {
> + size_t limit = git_alloc_limit ? git_alloc_limit : SIZE_MAX;
> + if (size > limit) {
> + if (verbose)
> error("attempting to allocate %"PRIuMAX" over limit %"PRIuMAX,
> (uintmax_t)size, (uintmax_t)git_alloc_limit);
> + return -1;
> }
> return 0;
> }
The code is prepared for a case where git_alloc_limit is set to 0,
in which case SIZE_MAX is used as a stand-in value. When the check
detects a request with overly large 'size', the error message tells
us that 'size' is over 'git_alloc_limit', the latter is zero and any
concrete value of 'size' certainly would be over that. Which may be a
bit confusing.
Shouldn't we be giving the local "limit" instead in the message?
next prev parent reply other threads:[~2026-09-21 21:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 13:02 [PATCH 0/6] [RFC] Create a 'safe' strbuf API Derrick Stolee via GitGitGadget
2026-09-18 13:02 ` [PATCH 1/6] strbuf: add header for 'safe' API Derrick Stolee via GitGitGadget
2026-09-21 21:18 ` Junio C Hamano
2026-09-23 19:25 ` Mark C. Chu-Carroll
2026-09-23 20:14 ` Junio C Hamano
2026-09-18 13:02 ` [PATCH 2/6] wrapper: initialize GIT_ALLOC_LIMIT proactively Derrick Stolee via GitGitGadget
2026-09-18 13:02 ` [PATCH 3/6] wrapper: create safe_memory_limit_check() Derrick Stolee via GitGitGadget
2026-09-21 21:24 ` Junio C Hamano [this message]
2026-09-18 13:02 ` [PATCH 4/6] strbuf-safe: add sstrbuf_grow() Derrick Stolee via GitGitGadget
2026-09-21 21:29 ` Junio C Hamano
2026-09-18 13:02 ` [PATCH 5/6] json-writer: include strbuf-safe.h Derrick Stolee via GitGitGadget
2026-09-18 13:02 ` [PATCH 6/6] strbuf-safe: add init and release methods Derrick Stolee via GitGitGadget
2026-09-21 21:44 ` Junio C Hamano
2026-09-21 22:34 ` Junio C Hamano
2026-09-19 15:23 ` [PATCH 0/6] [RFC] Create a 'safe' strbuf API Phillip Wood
2026-09-23 19:46 ` Jeff King
2026-10-06 14:33 ` Derrick Stolee
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=xmqqzexal2lv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=stolee@gmail.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