[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5175D52D.3050107@gentoo.org>
Date: Tue, 23 Apr 2013 02:26:21 +0200
From: Luca Barbato <lu_zero@...too.org>
To: musl@...ts.openwall.com
Subject: Re: Best place to discuss other lightweight libraries?
On 04/23/2013 01:06 AM, Rich Felker wrote:
> 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.
Usually (at least that's what I do in those case) the global logger is
overridden to use the outer library logger then you -end-user- override
it as well and then everything goes where you want.
The other widespread solution is to eat stderr and if something appears
show to the user, crude but not so bad.
>> 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...
Yeah, logging messages properly is terrible.
>>> 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.
C++ stock data structures are too runtime-dependent, crafting your own
means getting the worst of both words if you aren't extremely careful =\
Hopefully the new crop of system languages would try to capitalize on
the experience...
>> 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.
event loops, coroutines and threads have their uses.
>> 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.
There is always a tradeoff, reimplementing the wheel is ok if only
square ones are available.
>> 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
scatter-gather lists aren't that widespread =)
> 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.
Using snprintf in those cases doesn't scream efficient if I recall
correctly.
> 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.
That's more or less the annoying question: better to provide good
implementation of slightly dangerous to use code or let people bake
their own? (usually you have people using something not implemented
perfectly doesn't matter what, but again, tradeoffs...)
lu
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.
