From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3690 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Current status: important changes since 0.9.11 Date: Fri, 19 Jul 2013 15:54:00 -0400 Message-ID: <20130719195400.GA3249@brightrain.aerifal.cx> References: <20130719161234.GA8335@brightrain.aerifal.cx> <20130719203923.1a411332@ralda.gmx.de> <20130719185301.GJ12469@brightrain.aerifal.cx> <51E99856.3030504@gentoo.org> 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 1374263653 1365 80.91.229.3 (19 Jul 2013 19:54:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2013 19:54:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3694-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 19 21:54:15 2013 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 1V0Gko-0006bz-Rj for gllmg-musl@plane.gmane.org; Fri, 19 Jul 2013 21:54:14 +0200 Original-Received: (qmail 3078 invoked by uid 550); 19 Jul 2013 19:54:13 -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 2046 invoked from network); 19 Jul 2013 19:54:13 -0000 Content-Disposition: inline In-Reply-To: <51E99856.3030504@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3690 Archived-At: On Fri, Jul 19, 2013 at 09:49:42PM +0200, Luca Barbato wrote: > On 07/19/2013 08:53 PM, Rich Felker wrote: > > However I do also agree with you, and think simplicity/consistency > > possibly override reason #1 above, and #2 could easily be handled if > > some time is put into review and testing of the new code. > > > > Anyone else have opinions on the matter? > > According to what you said pathological compilers would be the problem here. Which comment are you referring to? > Not sure which would be the performance impact of the change on good > compilers though. This is code that runs once at startup and has no loops. There's really no way for it to be slow. The only issues are size and correctness. Rich