From: Brandon Casey <drafnel@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Fwd: permission to re-license strbuf subsystem as LGPL
Date: Fri, 23 Sep 2011 17:50:27 -0500 [thread overview]
Message-ID: <CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com> (raw)
In-Reply-To: <m3mxdvqj31.fsf@localhost.localdomain>
2011/9/23 Jakub Narebski <jnareb@gmail.com>:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> ---------- Forwarded message ----------
>> From: Brandon Casey <drafnel@gmail.com>
>> Date: Thu, Sep 22, 2011 at 11:21 PM
>> Subject: permission to re-license strbuf subsystem as LGPL
>>
>> To those who have contributed to git's strbuf subsystem,
>>
>> I'd like to turn git's strbufs into a library. So with your consent
>> I'd like to re-license the code in strbuf.c and strbuf.h, and any
>> compat/ dependencies as LGPL so that I can create a strbuf library.
>
> That's a laudable goal. Do you plan on librarizing other universal
> mini-libraries, like parseopt or test-lib?
Not at the moment.
> I wonder if for example "perf" tool in Linux kernel sources (userspace
> companion to perf events subsystem) will move to using it; currently
> it reuses some of internal git minilibraries, IIRC strbuf and parseopt
> included.
I would be pleased if it was useful to them.
> By the way, how the 'strbuf' from git (which I think was created among
> others to avoid additional external dependencies) differs from
> existing C (not C++) string libraries, like 'bstring'[1], The Better
> String Library, or the C libraries in http://bstring.sourceforge.net/features.html?
>
> [1]: http://bstring.sourceforge.net
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)
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.
-Brandon
next prev parent reply other threads:[~2011-09-23 22:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+sFfMeRDQiqGhO9Y=k3tEnzdXjMx59huFE_fx6Y14cJxj1J=Q@mail.gmail.com>
2011-09-23 15:01 ` Fwd: permission to re-license strbuf subsystem as LGPL Brandon Casey
2011-09-23 15:36 ` Michael Witten
2011-09-23 17:12 ` Fwd: " Jakub Narebski
2011-09-23 22:50 ` Brandon Casey [this message]
2011-09-24 6:05 ` Jeff King
2011-09-23 22:16 ` Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com \
--to=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).