Re: libcodecs(3), take 4

[Alistair Crooks <agc%pkgsrc.org@localhost>]

Hi Uebayashi-san,

Thanks for your feedback.

On Sat, Oct 02, 2010 at 02:42:02PM +0900, Masao Uebayashi wrote:
> Usually libraries don't print error messages to stderr, nor exit.

That's true for some libraries, but not for all of them.  At the same
time, printing error messages is far superior to the practise of
returning enumerated error values (like regexp libraries), or stacking
them up and vomiting them up at a later stage.
 
> I don't like regex usages; it increases failure points by doing memory
> allocation.  Normalization should be done in programs, not in libraries.

Well, on that point, we'll have to differ.  I have to say, though,
that it's a very, very low lowest common denominator to ban all kinds
of memory allocation from everything you do.  In fact, I think it's
just not possible to work with constraints like that in userland -- so
please don't try to force that on anyone.
 
> You keep confusing us to add "charset" functionality (leet this time)
> to libcodes(3), ignoring iconv(3).

Oh, sorry, I didn't make myself clear.  The "leet" transformation is
not part of libcodecs.  It's in a subdirectory called "example". 
There is a file called "HOWTO" in there, which shows how to add any
other transformation to libcodecs.

I am certainly not ignoring iconv, and I am not trying to re-invent
iconv.  On the contrary, I believe that iconv can be called from
libcodecs.  But I don't want it in the standard libcodecs
transformations.
 
> I hope this library becomes more modular.

You're going to have to help me out here - I have absolutely no idea
what you mean.
 
> OTOH I'm not convinced that the add operation's "usefulness".

The "add" operation (codecs_add()) will add a transformation to the table.
Is that what you mean?

Without it, there would be no transformations available. So still a bit
unclear what you mean by this.
 
> (I'd be nice if you consider to spend some more time to research existing
> libraries (especially Citrus iconv and libarchive), and listen to opinions
> of "library gurus"...)

I still think you're confusing a worked example for something else,
and drawing a whole lot of conclusions from that, and a whole lot more
besides.

Regards,
Alistair