From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC] cocci: .buf in a strbuf object can never be NULL
Date: Thu, 19 Mar 2026 22:45:04 -0700 [thread overview]
Message-ID: <xmqq341vgilb.fsf@gitster.g> (raw)
In-Reply-To: <20260320041803.GA18125@coredump.intra.peff.net> (Jeff King's message of "Fri, 20 Mar 2026 00:18:03 -0400")
Jeff King <peff@peff.net> writes:
> I'm not quite sure what you mean. The function right now looks like:
> ...
> But it's not quite enough to just do:
>
> free(buf);
>
> Because "buf" is a copy of sb->buf,...
I may have phrased the idea very poorly. In short, the core of the
idea is that we do not have to use the original content of the
strbuf at all. I.e., "buf" does not have to be anything related to
sb->buf.
In the following patch, I am _removing_ strbuf_reset() near the
beginning, but replacing it with strbuf_release() may illustrate the
idea more clearly. I didn't do so primarily because the first thing
strbuf_attach() does is to call strbuf_release(), so the call would
be redundant in the normal code flow.
When getdelim() did not return anything positive, after asserting
the return value is -1 (i.e., EOF), we only need to return EOF while
emptying the caller-supplied strbuf. As the "char *buf" we have and
passed to getdelim() never had anything to do with caller-supplied
strbuf *sb, there is no need to worry about slopbuf or anything
associated with it.
strbuf.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git c/strbuf.c w/strbuf.c
index 3939863cf3..ef61bd5b14 100644
--- c/strbuf.c
+++ w/strbuf.c
@@ -631,21 +631,20 @@ int strbuf_getcwd(struct strbuf *sb)
#ifdef HAVE_GETDELIM
int strbuf_getwholeline(struct strbuf *sb, FILE *fp, int term)
{
+ size_t alloc;
+ char *buf;
ssize_t r;
if (feof(fp))
return EOF;
- strbuf_reset(sb);
-
- /* Translate slopbuf to NULL, as we cannot call realloc on it */
- if (!sb->alloc)
- sb->buf = NULL;
+ buf = NULL;
+ alloc = 0;
errno = 0;
- r = getdelim(&sb->buf, &sb->alloc, term, fp);
+ r = getdelim(&buf, &alloc, term, fp);
if (r > 0) {
- sb->len = r;
+ strbuf_attach(sb, buf, (size_t) r, alloc);
return 0;
}
assert(r == -1);
@@ -664,15 +663,14 @@ int strbuf_getwholeline(struct strbuf *sb, FILE *fp, int term)
if (errno == ENOMEM)
die("Out of memory, getdelim failed");
- /*
- * Restore strbuf invariants; if getdelim left us with a NULL pointer,
- * we can just re-init, but otherwise we should make sure that our
- * length is empty, and that the result is NUL-terminated.
+ /*
+ * We got an EOF. If getdelim() allocated any memory, we
+ * would return that to the system.
*/
- if (!sb->buf)
- strbuf_init(sb, 0);
- else
- strbuf_reset(sb);
+ free(buf);
+
+ /* And empty the strbuf */
+ strbuf_release(sb);
return EOF;
}
#else
next prev parent reply other threads:[~2026-03-20 5:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 7:15 [PATCH] rerere: update to modern representation of empty strbufs Junio C Hamano
2026-03-19 7:57 ` Patrick Steinhardt
2026-03-19 22:14 ` [RFC] cocci: .buf in a strbuf object can never be NULL Junio C Hamano
2026-03-19 23:35 ` Jeff King
2026-03-20 1:46 ` Junio C Hamano
2026-03-20 4:18 ` Jeff King
2026-03-20 5:45 ` Junio C Hamano [this message]
2026-03-20 5:57 ` Jeff King
2026-03-20 6:06 ` Junio C Hamano
2026-03-20 6:18 ` Jeff King
2026-03-21 13:14 ` René Scharfe
2026-03-21 16:41 ` Jeff King
2026-03-21 20:47 ` René Scharfe
2026-03-21 21:18 ` Jeff King
2026-03-21 23:41 ` René Scharfe
2026-03-22 1:44 ` Jeff King
2026-03-22 1:22 ` Junio C Hamano
2026-03-22 1:40 ` Jeff King
2026-03-21 16:24 ` Junio C Hamano
2026-03-21 16:39 ` 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=xmqq341vgilb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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