Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Apr 2013 00:42:01 +0200
From: Luca Barbato <>
Subject: Re: Best place to discuss other lightweight libraries?

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:
> 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.

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

(In the specific case above there is a quite borderline solution since
we can override the global logger and store per context loggers in
creative ways)

> Really, the fact that they can fail and want to be able to report
> failure means they _do_ need a context, but I can understand the
> desire to cheat, especially if there's a performance cost to passing
> the context all the way down. In that case, hidden non-global state,
> namely thread-local storage, might be an appropriate solution. It's
> still hidden state (and thus A Bad Thing), but at least it's no longer
> global state.

Exactly. (bonus points if you do that in a void returning function...)

>>> - Designs based on shared libraries, especially lots of them. This
>>>   creates bloat and often interferes with the ability to use static
>>>   linking.
>> Special mention to those that want to do clever stuff on the init
>> section (e.g. change a program global state from there)
> Did whatever lib did that (OpenAL, was it?) ever fix their bugs?

Given recent binutils would strip away symbols if used that way, making
linking fail, I hope so.

> 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,
eventloops, threadpools and portable string mangling (e.g. strl*
functions) in a single widespread package.

Some lean/cleaned up alternative are cropping but usually they aren't as
known and widespread.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.