From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4815 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: build with clang-3.4 warnings report Date: Sun, 6 Apr 2014 12:49:07 -0400 Message-ID: <20140406164906.GZ26358@brightrain.aerifal.cx> References: <20140404204701.GO26358@brightrain.aerifal.cx> <533F56FB.8060509@embtoolkit.org> <20140405015443.GU26358@brightrain.aerifal.cx> <1396688698.11744.258.camel@eris.loria.fr> <20140405130700.GV26358@brightrain.aerifal.cx> <1396708669.11744.314.camel@eris.loria.fr> <20140405163512.GW26358@brightrain.aerifal.cx> <1396735703.11744.355.camel@eris.loria.fr> <20140406015709.GX26358@brightrain.aerifal.cx> <1396802239.11744.385.camel@eris.loria.fr> 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 1396802967 30206 80.91.229.3 (6 Apr 2014 16:49:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Apr 2014 16:49:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4819-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 06 18:49:21 2014 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 1WWqG0-0007Np-8o for gllmg-musl@plane.gmane.org; Sun, 06 Apr 2014 18:49:20 +0200 Original-Received: (qmail 14307 invoked by uid 550); 6 Apr 2014 16:49:19 -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 14299 invoked from network); 6 Apr 2014 16:49:18 -0000 Content-Disposition: inline In-Reply-To: <1396802239.11744.385.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4815 Archived-At: On Sun, Apr 06, 2014 at 06:37:19PM +0200, Jens Gustedt wrote: > Am Samstag, den 05.04.2014, 21:57 -0400 schrieb Rich Felker: > > As usual you're the master of preprocessor tricks. Overall I like it, > > but it's still not as efficient as what we have now. > > If space efficiency is really as important, you could be thinking of > compressing all that strings, there is a lot of redundancy in the > text. *sigh* This was all discussed in the last bikeshed. Compressing it just moves all the size from shared text to non-shared data, not to mention adding the code size of a decompressor. And you can't just decompress one string at a time in a small buffer because the contract of musl's strerror is that the returned string is immutable/permanently valid. This is necessary to make implementing printf, strerror_r, etc. in terms of strerror possible, which in turn is needed to make them efficient (otherwise you need a horrible retry loop dynamically allocating larger buffer space, etc.) The question is not whether space efficiency is really important, but whether there's a justification for enlarging a function when the increase in size has no practical benefits. And I think a majority of our users would say the answer is no. I agree that your version is mildly more elegant, and if I'd thought of it first that's probably what I would have used from the beginning, but I can't see explaining to users a size increase for the sake of mild elegance. Rich