From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1662 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Todo for release? Date: Wed, 22 Aug 2012 14:57:09 -0400 Message-ID: <20120822185709.GG27715@brightrain.aerifal.cx> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120815040836.GJ27715@brightrain.aerifal.cx> <20120815102029.GL20243@port70.net> <20120815133257.GM20243@port70.net> <20120815143640.GM27715@brightrain.aerifal.cx> <20120817094901.GA16602@port70.net> <20120817121059.GT27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1345661744 18949 80.91.229.3 (22 Aug 2012 18:55:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2012 18:55:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1663-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 22 20:55:43 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 1T4G5d-0005N6-6B for gllmg-musl@plane.gmane.org; Wed, 22 Aug 2012 20:55:41 +0200 Original-Received: (qmail 9800 invoked by uid 550); 22 Aug 2012 18:55:39 -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 9791 invoked from network); 22 Aug 2012 18:55:38 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1662 Archived-At: On Wed, Aug 22, 2012 at 07:45:01PM +0200, Daniel Cegiełka wrote: > Hi, > Very helpful would be support for fts.h in musl: > > http://www.kernel.org/doc/man-pages/online/pages/man3/fts.3.html Can these functions be implemented purely as library functionality, without any hooks into libc internals? I was thinking it might be nice to isolate all such code into a single subtree in musl, so that folks wanting to use it outside musl (either directly in application source trees, or in libraries) could easily find and use it. Of course there's also the option of putting such code in a separate library outside of libc (i.e. not including it in libc) which some people might prefer, but if it's small and historically in libcs and doesn't create maintenance burden, I'm not opposed to having it in libc.. Rich