From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1856 Path: news.gmane.org!not-for-mail From: Gregor Richards Newsgroups: gmane.linux.lib.musl.general Subject: Re: Musl-extra: C general-purpose and utility library Date: Fri, 07 Sep 2012 09:38:17 -0400 Message-ID: <5049F8C9.9070801@purdue.edu> References: <20120907130412.25ecfd90@gmail.com> <20120907133147.GN27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347025117 2204 80.91.229.3 (7 Sep 2012 13:38:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2012 13:38:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1857-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 07 15:38:37 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T9ylY-000211-R3 for gllmg-musl@plane.gmane.org; Fri, 07 Sep 2012 15:38:36 +0200 Original-Received: (qmail 11762 invoked by uid 550); 7 Sep 2012 13:38:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11745 invoked from network); 7 Sep 2012 13:38:33 -0000 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 In-Reply-To: <20120907133147.GN27715@brightrain.aerifal.cx> X-PMX-Version: 5.5.9.388399 X-PerlMx-Virus-Scanned: Yes Xref: news.gmane.org gmane.linux.lib.musl.general:1856 Archived-At: 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