Re: Best place to discuss other lightweight libraries?

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 23, 2013 at 12:42:01AM +0200, Luca Barbato wrote:
> On 04/22/2013 11:52 PM, Rich Felker wrote:
> >> For this there aren't solution that won't cause different problems I'm
> >> afraid.
> > 
> > Sure there are. I get the impression you can tell I was talking about
> > libav/ffmpeg's log interface. :-) The obvious solution is to bind log
> > contexts to the object you're acting on. See this nice talk:
> > 
> > http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-singletons/
> > 
> > If I remember right, part of the problem way back was that there were
> > deep function calls that had no context available to them, and that
> > didn't _need_ a context for anything but logging warnings or whatnot.
> 
> In the specific case yes. I tried to foster proper return error
> propagation, so you get something more meaningful than EINVAL/-1 and
> that is usually enough in those specific cases.
> 
> The general problem is that the library user wants to be the only one
> having a say on what goes where so single point overrides are useful.

The problem with your comment here is the phrase "library user". Who
is the library user? You may be thinking from a standpoint (in our
example) of MPlayer, but what if instead the application you were
looking at were a file manager that itself had no awareness of video
files, and only ended up processing them as part of a library pulled
in from a plugin for file previews? Obviously there is no way the app
can be aware of where the log messages should go since it's not aware
the library even exists. The user is the library that depends on the
library doing the logging, not the app, and it's very possible that
there is more than once such library. In which case, you have madness.

> When you start using those libraries in situations in which you'd like
> to have per-$situation logging then you start to scream.

Keep in mind it might not even be "per-situation logging". It might be
something like one plugin needing to send the message back up to the
application as a popup message to display, and another plugin just
wanting to render the message text as a file preview in place of an
image...

> > Yes, basically. Dependency on glib means your library will impose
> > bloat and it will preclude robustness.
> 
> Yet glib gives you oh-so-many-features (I fell for it once), sadly there
> aren't many utility libs that provide sort of useful data structures,

If you want the data structures, I think that means you should be
using C++, not C.

> eventloops,

If your program is event-loop-performance-critical (think httpd), you
probably need a custom one for your application.

If it's not, you could probably write a much simpler program using
threads. It might even perform better too.

> threadpools

Similar situation. Threadpools are an optimization that shouldn't be
applied prematurely, and if you do need them, you probably want a
custom solution.

> and portable string mangling (e.g. strl*
> functions) in a single widespread package.

strl* considered harmful, for 3 reasons:

1. Concatenation is a bad idiom. See
http://en.wikipedia.org/wiki/Schlemiel_the_Painter's_algorithm

2. It duplicates standard functionality in snprintf. Yes it's quicker
for some cases (pure copying), but in that case you probably should
just be using the original string in-place. On the other hand,
building the whole output in one step with snprintf makes it obvious
that your code is correct and avoids issue #1 above.

3. While returning the length that "would be needed" is useful if you
want to allocate and retry, it's harmful if your goal is to protect
against malicious inputs. For instance,

    strlcpy(buf, some_500_gb_string, 10)

has to process the whole input string even though it's going to throw
away most of it. BTW this issue applies to snprintf too, but at least
it has something useful to be computing. With strl*, the return value
is always something that would be trivial to obtain yourself if you
needed it.

I'm aware some people like strl* and we have them in musl because it's
better to provide them than to deal with people rolling their own and
doing it in wrong and insecure ways. But I still would recommend
against using them in new code.

Rich