Re: Fwd: permission to re-license strbuf subsystem as LGPL

[Jeff King <peff@peff.net>]

On Fri, Sep 23, 2011 at 05:50:27PM -0500, Brandon Casey wrote:

> Hmm, I forgot about bstring.  I think strbuf is a little smaller in
> scope than bstring, perhaps less ambitious.  Less abstraction, and
> less protection too.  With strbuf, you never forget that you're
> dealing with C char arrays.  The data structures are pretty similar,
> but I don't think strbuf will ever have a function like
> 
>    bconcat(bstring1, bstring2)
> 
> instead, you'd just do
> 
>    strbuf_add(strbuf1, strbuf2.buf, strbuf2.len)

I think it's spelled:

  strbuf_addbuf(strbuf1, strbuf2);

in the current code.

> The benefit, of course, of a bconcat function is that either bstring1
> or bstring2 can be NULL (like if a previous bstring2 = bfromcstr()
> initialization failed).  This allows you to perform a sequence of
> bstring operations and only check errors at the end.

There is no error checking with strbufs at all. The only thing that can
fail is malloc, and in that case, we always die().

It wouldn't be too hard to make it return errors (or set a global error
flag), and have any failed mallocs just leave the strbuf unchanged.
Because strbufs are always in a consistent state, it would be safe to
do:

  global_strbuf_error_flag = 0;
  strbuf_addbuf(strbuf1, strbuf2);
  strbuf_addbuf(strbuf3, strbuf1);
  strbuf_addbuf(strbuf3, strbuf4);
  if (global_strbuf_error_flag)
    ...

The contents of the strbufs would be indeterminant, but you would never
have violated any memory constraints.

-Peff