Re: Best place to discuss other lightweight libraries?

[Rich Felker <dalias@aerifal.cx>]

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