Re: [PATCH 1/6] strbuf: add header for 'safe' API

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2026, 21:18 UTC
Message-ID: <xmqq4ifimhfr.fsf@gitster.g>
In-Reply-To: <b1779709120adc9c1df40c7210481d6bed9791c5.1789736540.git.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 12 quoted lines

> +/*
> + * NOTE FOR STRBUF DEVELOPERS
> + *
> + * strbuf is a low-level primitive; as such it should interact only
> + * with other low-level primitives. Do not introduce new functions
> + * which interact with higher-level APIs.
> + *
> + * This header file specifically conatins the "safe" API surface for
> + * working with strbufs. The implementations of these methods avoid
> + * using die() and other exits. Thus, these methods are appropriate
> + * for use within lower-level APIs such as trace2.
> + */

I have to wonder if this is somewhat backwards, in that the longer term goal for us should be to make most of the service routines like strbuf, string_list, csum_file, etc., free of die() and be "safe".

A recent trend under the label "libification" is to make the use of the_repository more explicit and pass a "struct repository *" as a parameter instead more widely throughout the code flow, but it would be equally if not more useful change to expand the "safe" API surface so that callers of more service routines take responsibility to act on errors.

And picking strbuf as the first instance of such generic service library certainly is a good idea. Its interface is well defined.

We may want to rename functions that _happen_ to use a strbuf to return their results but otherwise has nothing to do with strbuf away from strbuf_ prefix (strbuf_realpath() etc. in abspath.h are prime examples) as part of this first step, though.