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

> 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.

> 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.