Date: Mon, 22 Apr 2013 19:06:28 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Best place to discuss other lightweight libraries? 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
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.