Musl-extra: C general-purpose and utility library

Musl-extra: C general-purpose and utility library

[philomath]

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?

Bye.

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

[Rich Felker]

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

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

[Gregor Richards]

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

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

[Rich Felker]

On Fri, Sep 07, 2012 at 09:38:17AM -0400, Gregor Richards wrote:
> 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.

This is a very interesting idea. Very different from what philomath
proposed, of course.

Rich

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

[Arvid E. Picciani]

On Fri, 7 Sep 2012 09:31:47 -0400, Rich Felker wrote:

> 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.

for C++? pretty hard to do that, the language is horrible already :/
I like Qt, since it doesn't even try to follow the C++ spirit,
but then again its weird on its own.

Indeed, C is not the place to do high level stuff in.
I'm still waiting for clay [http://claylabs.com/clay/] to become 
usable,
before dropping C++ for system services.


-- 
Arvid E. Picciani

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

[Luca Barbato]

On 9/19/12 10:38 AM, Arvid E. Picciani wrote:
> On Fri, 7 Sep 2012 09:31:47 -0400, Rich Felker wrote:
>
>> 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.
>
> for C++? pretty hard to do that, the language is horrible already :/
> I like Qt, since it doesn't even try to follow the C++ spirit,
> but then again its weird on its own.
>
> Indeed, C is not the place to do high level stuff in.
> I'm still waiting for clay [http://claylabs.com/clay/] to become usable,
> before dropping C++ for system services.

Clay uses llvm so till somebody doesn't make a C compiler out of it (or 
make the gcc backend have a decent api like llvm) you will need a C++ 
standard library.

lu