From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/50 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Cleanup patches Date: Tue, 7 Jun 2011 11:39:18 -0400 Message-ID: <20110607153918.GI191@brightrain.aerifal.cx> References: <60BABB60-7D9B-4D66-8645-4CDFD07E1338@palsenberg.com> <20110606171317.GN6142@port70.net> <20110606173210.GD191@brightrain.aerifal.cx> <495DC2BF-B857-4BD5-95B1-753C0DB0DE6A@palsenberg.com> <20110607145149.GH191@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1307461605 3340 80.91.229.12 (7 Jun 2011 15:46:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Jun 2011 15:46:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-134-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 07 17:46:42 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QTyUM-0008As-2A for gllmg-musl@lo.gmane.org; Tue, 07 Jun 2011 17:46:42 +0200 Original-Received: (qmail 27808 invoked by uid 550); 7 Jun 2011 15:46:41 -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 27796 invoked from network); 7 Jun 2011 15:46:41 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:50 Archived-At: On Tue, Jun 07, 2011 at 05:26:22PM +0200, Igmar Palsenberg wrote: > The assembler doesn't see those flags. Those flags are simply > ignore, but clang does complain about them. What about things like -m32? Surely that affects the assembler. > >> I need to check. I get out of bounds warning with this code. I'll > >> check and update this code. > > > > Yes, you'll get array bounds warnings. You can leave this warning off > > unless clang is really miscompiling the code, in which case I'll have > > to make some larger changes... > > Probably not. I might run a case through valgrind to see if it comes up (and if possible, since the last time I checked valgrind, it couldn't handle static binaries). Just test malloc and make sure it works. If clang generated wrong code, it will fail catastrophically. > >>> I'm guessing this might be an issue of some 32-bit x86 compilers > >>> disagreeing on whether wchar_t is "int" or "long". Traditionally it > >>> was "long" which worked but was obviously stupid conceptually. I don't > >>> know a good way to make musl's wchar.h adapt to what the compiler > >>> wants though... > >> > >> The cast should be OK. In cases where it is correct (and the cast > >> isn't necessary), it is simply a NOOP. > > > > No, the cast, like ALMOST ALL CASTS, hides a bug: that wchar_t is > > defined in an inconsistent way. It's actively harmful. > > I'll make a proper fix for that. I think it should be fixed in git. Please tell me if it's not. > The code is normally something like : > > weak_alias(real, alias); > where real is a static function. > > clang then barked about the function being unused. If I expand the > macro (gcc -E), and replace weak_alias(...) with the expanded form, > I get an error that an alias won't work on a static function. Are you sure you didn't botch the macro expansion? If you did it right and the warnings/errors differ, that's a bug in clang, I think... Can you show an example of the expansion you did? (just the relevant lines) > I need to dive into this to see who to blame :) :) Rich