[ccan] New module: bdelta

[Rusty Russell]

On Sun, 21 Aug 2011 21:04:49 -0400, Joey Adams <joeyadams3.14159 at gmail.com> wrote:
> On Sun, Aug 21, 2011 at 7:12 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> > On Fri, 19 Aug 2011 10:41:33 -0400, Joey Adams <joeyadams3.14159 at gmail.com> wrote:
> >> I was going to use an enum, but what would I call it?  Remember that
> >> C++ would treat enum bdelta {...} as a type definition (rather than
> >> simply an enum tag), meaning "bdelta" could no longer be used as a
> >> variable name.
> >
> > I don't really care about C++, but enum bdelta seems wrong anyway:
> > bdelta_err maybe?
> 
> I went with BDELTAcode (as mentioned in my last patch-laden e-mail).
> It's slightly ugly, but it's the closest I could get to "consistency",
> as it's what libcurl uses.

OK, I've applied and pushed your latest version.

> typedef enum {...} bdelta_err would be fine, too.  Actually, it'd
> probably be better, as other modules could follow bdelta's lead
> without it looking horribly ugly (e.g. OGG_TO_PCMcode).

> > ...   I've found that generally when coders try to use perror it makes their code worse.
> 
> What about when they don't check error codes at all?

Well, as a great philosopher once said, "you can't hug every cat".

> bdelta has its own private string buffer implementation, which would
> arguably make a good CCAN library on its own.  However:
> 
>  * I don't have the time or interest to develop, document, test, and
> review a second module (for the time being).
> 
>  * I strive for standalone modules, as they're easier to grab and
> integrate into a project, as well as to study.  Even if I implemented
> ccan/sb, I wouldn't want bdelta to depend on it.  Other diff
> implementations I found were either mired in application code (e.g.
> rsync, git) or in themselves (e.g. libxdiff), making them hard to
> integrate.

Indeed.  There is a cost to modularization, in usability and clarity.

Thanks,
Rusty.