From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2522 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Agenda for next release? Date: Mon, 31 Dec 2012 14:11:31 -0500 Message-ID: <20121231191131.GA18334@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1356981108 4617 80.91.229.3 (31 Dec 2012 19:11:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 19:11:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2523-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 31 20:12:04 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 1TpkmF-0002j4-5N for gllmg-musl@plane.gmane.org; Mon, 31 Dec 2012 20:11:59 +0100 Original-Received: (qmail 31876 invoked by uid 550); 31 Dec 2012 19:11:43 -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 31868 invoked from network); 31 Dec 2012 19:11:43 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2522 Archived-At: Hi, I don't have any immediate plan for the next release, but I'd like to start thinking about what we'd like to go into it. A few things I know are still pending that should be possible to include are: - strverscmp - zoneinfo - inet_makeaddr - scanf %m modifier - getifaddrs - cpuset/affinity interfaces - ether.h interfaces I know there's also interest in exposing sigreturn and setcontext for libunwind use, but it's difficult to do right and I'm really skeptical of the whole thing. Their use of sigreturn seems completely incorrect (and thus probably untested); sigreturn expects a struct sigcontext on the stack, not a pointer to a sigcontext in the first function argument slot. I would rather have a conversation with their developers first to determine if that code is even working/valid, and defer the corresponding additions to musl until we eventually add all the ucontext.h interfaces in working form. Another port (perhaps x32, like originally proposed) is also definitely an option if anybody's up for doing it. I had considered doing it myself in this release cycle, but I'm a bit busy with some other projects for at least a couple weeks so I'd rather not get bogged down in a big time-eater right away, and instead spend my time with musl on small isolated feature additions and bug fixes. Anything else I missed? Rich