[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5049F8C9.9070801@purdue.edu>
Date: Fri, 07 Sep 2012 09:38:17 -0400
From: Gregor Richards <gr@...due.edu>
To: musl@...ts.openwall.com
Subject: Re: Musl-extra: C general-purpose and utility library
On 09/07/2012 09:31 AM, Rich Felker wrote:
> 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
I'm inclined to point out that there's another side to this coin:
Although we all like to fault gnulib for having a bunch of unportable
and unwise garbage, the vast majority of gnulib is portable
implementations of functions that the libcs frequently get wrong. As
usual, GNU is the worst user of gnulib, so we get a contorted view.
Much of musl could be extracted for similar purpose, but under a less
painful license and with less bloat from supporting systems so ancient
they're irrelevant and won't work anyway.
With valediction,
- Gregor Richards
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.
