From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4806 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: build with clang-3.4 warnings report Date: Sat, 5 Apr 2014 11:31:15 +0200 Message-ID: <20140405093115.GK3034@port70.net> References: <533F0F1A.6040707@embtoolkit.org> <20140404204701.GO26358@brightrain.aerifal.cx> <533F56FB.8060509@embtoolkit.org> <20140405015443.GU26358@brightrain.aerifal.cx> <1396688698.11744.258.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 1396690296 14295 80.91.229.3 (5 Apr 2014 09:31:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Apr 2014 09:31:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4810-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 05 11:31:29 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 1WWMwi-00060l-OD for gllmg-musl@plane.gmane.org; Sat, 05 Apr 2014 11:31:28 +0200 Original-Received: (qmail 16291 invoked by uid 550); 5 Apr 2014 09:31:27 -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 16283 invoked from network); 5 Apr 2014 09:31:27 -0000 Content-Disposition: inline In-Reply-To: <1396688698.11744.258.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4806 Archived-At: * Jens Gustedt [2014-04-05 11:04:58 +0200]: > This seems to come from the bogus handling of EDQUOT by mips: > > /* mips has one error code outside of the 8-bit range due to a > * historical typo, so we just remap it. */ > > This remapping seems only to have been done correctly for the strerror > function itself but not for the array declaration. > > An equivalent patch for that line would be > > #define E(a,b) (unsigned char)((EDQUOT==1133 && (a)==EDQUOT) ? 109 : a), > > but which makes it only apparent how bogus this is. the cast should be fine 1133%256 == 109 and 109 is an unused errno number on mips (this is why the mips bug can be worked around and yes it's ugly but at least it does not penalize other archs) > To "repair" the mips problem I would just do > > I think the real bug is here > > #define E(a,b) ((unsigned char)a), > > this is a typical case of someone using a cast to burry a > problem, black magic, "casting a spell". you forgot to write what would you do :) the cast hides a compiler warning about the >UCHAR_MAX errno (making the warning visible makes sense, however i highly doubt there ever will be another broken errno) > As this bug shows, the whole technique of searching the error string > in strerror is somehow fragile. > > The whole thing could be avoided by using designated initializers and > eliminating the whole errid array right away. Designated initializers > should be present in all decent versions of gcc. Do you want me to > prepare a patch? how? strerror is size optimized (there are various ways to do strerror, but i could not improve on rich's code)