From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3136 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best place to discuss other lightweight libraries? Date: Mon, 22 Apr 2013 10:53:46 -0400 Message-ID: <20130422145346.GP20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366642441 820 80.91.229.3 (22 Apr 2013 14:54:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2013 14:54:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3140-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 22 16:54:05 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 1UUI7z-0006sd-Uv for gllmg-musl@plane.gmane.org; Mon, 22 Apr 2013 16:54:00 +0200 Original-Received: (qmail 17950 invoked by uid 550); 22 Apr 2013 14:53:59 -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 17942 invoked from network); 22 Apr 2013 14:53:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3136 Archived-At: On Sun, Apr 21, 2013 at 12:30:54PM -0400, LM wrote: > Musl does a great job of replacing glibc. It's lightweight, > well-designed and written with friendly licensing. However, I'm > noticing there are a lot of other standard libraries and tools on a > typical system and often many of them are bloated or not so well > designed. I've been looking for a good forum to discuss using > alternative libraries and tools. I've checked out projects like I have no objection to discussion on this list, at least for the time being. If it becomes too much clutter, I might request later that we move such discussions to a separate list, but for now, go ahead. We've already had a few past discussions along these lines. For what it's worth, I think poor design is really the core of the problem. Bloat often stems from the effort needed to work around the bad design. The major design issues I've seen in widespread libraries are: - Tacking on error handling as an afterthought or not at all. This leads to ugly things like the caller having to setup a jmp_buf for the library to bail out on error (likely leaking lots of memory in the process) or just aborting the program on error. Sometimes the hacks like longjmp are added in ways that they're not safe with multiple users of the library or with threads. - Multiple "portable runtime" layers to do things the standard library already does, usually in less-portable or buggy ways. - Making a big deal out of string handling. Ugly OO-in-C string types with dynamic allocation and slow concatenation operations all over the place. Basically, anything that's generating strings any way other than snprintf/asprintf, unless it's performance-critical, is broken. - Gratuitous OO design. Good OO in C is having the complex or long-lived objects your library deals with well-encapsulated by library functions, and fully self-contained, without global state. Bad OO in C is reimplementing the C++ STL in C, with things like container objects, iterator objects, string objects, etc., as well as trying to do any global-level inheritance. As a clarification, things like implementing multiple video decoders that inherit an interface from a base "class" is reasonable; making every single object in your library derive from something like "GObject" is not. - Gratuitous ugly typedefs, especially as part of the external API, and especially when they duplicate standard types (INT, gint, etc.). - Interfaces that encourage or require UB to use them. One example that comes to mind is functions with signatures like posix_memalign which take a void** argument to store the result of an allocation. This encourages things like (void **)&ptr where ptr has type int*, for example. - Thread allergies, i.e. horribly over-complicating program logic to avoid threads. The best examples I can think of are the added logic needed to generalize a program that's reading from ordinary file descriptors (e.g. connection sockets) in an event loop to support SSL sockets or zlib-compressed streams. (Note: there are ways to address this kind of problem more cleanly without threads too, but nobody does it. I can elaborate if anybody's interested.) - DBus. - Use of global state. Even seemingly-harmless things like a global registered log function are harmful, because two different libraries (or the main program and a library) might be trying to use the library with the global log destination, and clobbering each other's choices. - Designs based on shared libraries, especially lots of them. This creates bloat and often interferes with the ability to use static linking. - Excessive dependence on external files and filesystem layout. This conflicts with easily migrating the binaries to other machines. - Dependency on any library with the above problems. :-) Rich