Re: Musl-extra: C general-purpose and utility library

[Rich Felker <dalias@aerifal.cx>]

On Fri, Sep 07, 2012 at 01:04:12PM +0200, philomath wrote:
> Hi,
> 
> (sorry for the title, I couldn't resist...)
> 
> During the recent discussions about feature-test-macros and libcap, it occurred
> to me that we need a unified good general-purpose C library (with "good"
> being understood as in musl's spirit).
> Musl at it's core aims to be a standards-compliant libc, and minimalistic at
> that, that's great. but it also brings in extra baggage, plus it has no place
> for data-structures, algorithms, and general utility functions.
> 
> Maybe we should only implement in musl the absolute minimum, and move
> everything else to musl-extra.  there we would create something like an
> alternative to Glib (and -shudder- gnulib) that sucks less (or even rocks). we
> can build on libraries such as plan9's, DJB and derivatives, etc (taking the
> good from the bed). in affect creating our own standards with no nonsense
> baggage.  who knows, in years to come we may all be working on the SMS (single
> musl specification).
> 
> Or maybe I should stop dreaming and get some work done?

I think what you're proposing is actually extremely difficult. Most of
what makes working C in valuable is doing your data structures without
generic containers. Having a binary search that operates on a static
const array, or putting your objects in one or more linked lists by
having prev/next pointers embedded in the structure rather than using
a container object for the list.

Once you move to using generic data structure implementations, the
complexity of managing allocations (and allocation failure!) increases
drastically. This is why most libraries like glib don't even bother to
do it right, and just crash when they run out of memory.

I'd love to be proven wrong, but so far my view is that if you want to
be using generic data structure classes, you should be using C++ or
another higher-level language. Doing it in C gives you all of the same
disadvantages (bloat, performance, impossibility of writing fail-safe
code with no allocations) but fails to give you many of the advantages
(for example, exceptions, which help you deal with the added
complexity of allocation failure, and syntactic sugar).

Personally, I think a clean, sane, bloat-free implementation of the
C++ standard library would be a lot more valuable for this kind of
work than a new non-standardized C library.

Rich