Re: [PATCH 0/6] [RFC] Create a 'safe' strbuf API

[Derrick Stolee <stolee@gmail.com>]

On 9/23/2026 3:46 PM, Jeff King wrote:
> On Sat, Sep 19, 2026 at 04:23:41PM +0100, Phillip Wood wrote:
> 
>>> The goal of this short RFC, such as it is, is to get some feedback on
>>> whether this is a worthwhile direction to pursue or if I should abandon this
>>> idea of having this definition of "safe" for some APIs. This decision may
>>> also determine if we should abandon ds/trace2-tolerate-failed-timestamps or
>>> leave the existing behavior as-is.

> Yeah, I don't love the term "safe" here for two reasons:
...> So what I had imagined when seeing the initial subject lines was not
> strbufs who report malloc errors, but rather strbuf-like functions that
> operate on a fixed-size buffer (with either a static max-size like 4k,
> or perhaps a per-variable max-size recorded in the struct).
> 
> You can still run into errors, of course; we might run out of room in
> the buffer. But we'd see those cases deterministically for a given
> input, rather than occasionally when races or other external factors
> cause malloc to unexpectedly fail.
> 
>> For the strbuf API having to check for failure on every function call does
>> not sound attractive, I think having a sticky error bit like the stdio
>> functions so that one can build a string and check there have been no
>> failures once just before using it would be a nicer approach.
> 
> Agreed. I think that is a good approach for the static_strbuf idea
> above, too.
Thanks for taking the time to consider the RFC. Sorry I'm so late in
responding, but I find your feedback insightful. It requires starting
over on this direction, but I don't currently have time to do so.
Maybe I'll give this a try again in the future, but I'll set it down
for now.

Thanks,
-Stolee