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

From: Jeff King <peff@peff.net>
Date: Sep 24, 2011, 06:05 UTC
Message-ID: <20110924060540.GA13974@sigill.intra.peff.net>
In-Reply-To: <CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com>

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

Show 11 quoted lines

> 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