Thread (16 messages) 16 messages, 5 authors, 7d ago

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

From: Junio C Hamano <hidden>
Date: 2026-09-21 21:18:50

"Derrick Stolee via GitGitGadget" [off-list ref] writes:
+/*
+ * 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help