From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9228 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Open/pending issues as of Jan 17 Date: Thu, 28 Jan 2016 21:34:45 -0500 Message-ID: <20160129023444.GT238@brightrain.aerifal.cx> References: <20160117231554.GA19126@brightrain.aerifal.cx> <20160118112530.GB9621@port70.net> 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 1454034901 6015 80.91.229.3 (29 Jan 2016 02:35:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2016 02:35:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9241-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 29 03:35:01 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aOyto-00062L-T2 for gllmg-musl@m.gmane.org; Fri, 29 Jan 2016 03:35:01 +0100 Original-Received: (qmail 5896 invoked by uid 550); 29 Jan 2016 02:34:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5876 invoked from network); 29 Jan 2016 02:34:58 -0000 Content-Disposition: inline In-Reply-To: <20160118112530.GB9621@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9228 Archived-At: On Mon, Jan 18, 2016 at 12:25:30PM +0100, Szabolcs Nagy wrote: > random stuff: > - linux 4.* uapi (includes mlock2, but a lot of other stuff too) Done. > - symbol versioning (for at least gcc-6 libgcc_s.so) This is a fairly invasive change and needs testing and possibly further discussion. It's big enough I'd like to allocate it attention on the roadmap for a specific release cycle. It's tentatively a secondary target for the next cycle but we could move it up to primary if this is becoming a serious problem. > - __cxa_thread_atexit_impl ? (i expect this to come up in real code) It looks to me like gcc emulates it with a pthread key to get a dtor and doesn't actually need help from the libc. If so I don't think it makes sense to bother with doing a better implementation on the libc side unless/until we can resolve the lazy allocation bug in their ABI. > - stdatomic.h Let's look at this later. > - string functions correctness I don't think there's much that can be done aside from adding the may_alias attribute. But at least that small improvement can go on the agenda for the next release cycle. > - regex bre extensions \+ \? \| Possibly going to apply this now unless you see a risk of breaking anything else. > - regcomp increase tre_stack_new limit Sounds ok to apply now but I lost track of where the patch is. > - str{f,p}time %z %Z %k %l ? > - noreturn __assert_fail ? > - hidden visibility for internal functions Let's look at these after release. > - compiler builtins in libc (sqrt, fabs, memcpy..) > - asm -> inline asm A little bit of this was done (for arm) but I'd like to continue where it makes sense. > - ld128 math Yes, that would be nice. Should we set a specific roadmap goal for adding it or at least adding the most important stuff (like sqrtl) that's currently badly broken. Rich