From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3143 Path: news.gmane.org!not-for-mail From: Luca Barbato Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best place to discuss other lightweight libraries? Date: Tue, 23 Apr 2013 00:42:01 +0200 Message-ID: <5175BCB9.5090309@gentoo.org> References: <20130422145346.GP20323@brightrain.aerifal.cx> <51755575.9030809@gentoo.org> <20130422215248.GR20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1366670535 18303 80.91.229.3 (22 Apr 2013 22:42:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2013 22:42:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3147-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 23 00:42:19 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UUPRB-0007Z7-2N for gllmg-musl@plane.gmane.org; Tue, 23 Apr 2013 00:42:17 +0200 Original-Received: (qmail 11787 invoked by uid 550); 22 Apr 2013 22:42:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11779 invoked from network); 22 Apr 2013 22:42:15 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130411 Thunderbird/17.0.5 In-Reply-To: <20130422215248.GR20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3143 Archived-At: 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. 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. lu