From: Jeff King <peff@peff.net>
Date: Sat, 21 Mar 2026 16:39:41 GMT
Subject: Re: [RFC] cocci: .buf in a strbuf object can never be NULL
Message-ID: <20260321163941.GA717067@coredump.intra.peff.net>
In-Reply-To: <xmqqqzpdb172.fsf@gitster.g>

On Sat, Mar 21, 2026 at 09:24:17AM -0700, Junio C Hamano wrote:

> Here is my second try.  strbuf_getwholeline() does not have to break
> strbuf invariants even tentatively.  We just grab the guts of sb,
> let getdelim() possibly reallocate, and then return it in the normal
> case.
> 
> In the EOF code path, the only special thing we need is when we
> started with slopbuf[] and getdelim() allocated some bytes yet
> returned EOF.  We are expected to free it before returning.

This is similar to what I initially wrote (but revised before sending),
but I don't think it works because...

> +	/* 
> +	 * We haven't touched sb at all; as with the initial "were we
> +	 * already at EOF?" case, return EOF without touching sb.
>  	 */

...this part isn't necessarily true. We handed sb->buf (copied via the
local "buf") to getdelim(). It might have reallocated it behind our
backs and returned the new pointer, and now sb->buf is dangling.

And in that sense, assigning sb->buf to a local buf becomes _more_
confusing, because now we have two copies of a pointer that is being
mutated.

> By the way, the big comment about xrealloc() in the middle, most of
> which is outside the post-context of the first hunk, should be
> updated, as our xrealloc() do not aggressively try to recover these
> days, if I understand correctly.  I left it outside the scope of
> this patch, whose sole focus is to reduce the number of places in
> the codebase that check if sb->buf is NULL.

Yes, I think you're right.

-Peff