[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130422145346.GP20323@brightrain.aerifal.cx>
Date: Mon, 22 Apr 2013 10:53:46 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Best place to discuss other lightweight libraries?
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
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.
