From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2576 Path: news.gmane.org!not-for-mail From: Vasily Kulikov Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl as a framework to test applications' compatibility with POSIX (was: NULL) Date: Mon, 14 Jan 2013 18:30:25 +0400 Message-ID: <20130114143025.GA12142@cachalot> References: <20130113174731.GS4468@port70.net> <1358106388.32505.17@driftwood> <20130114061135.GM20323@brightrain.aerifal.cx> <20130114084527.GA4055@cachalot> <20130114140334.GA29049@brightrain.aerifal.cx> 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 1358173847 23345 80.91.229.3 (14 Jan 2013 14:30:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 14:30:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2577-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 14 15:31:04 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 1Tul3v-0001DI-Vp for gllmg-musl@plane.gmane.org; Mon, 14 Jan 2013 15:30:56 +0100 Original-Received: (qmail 19865 invoked by uid 550); 14 Jan 2013 14:30:39 -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 19857 invoked from network); 14 Jan 2013 14:30:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=lDSTKnVx6DUvTul5rfEizqcR4TDkx8LfVbzl/OYLP9k=; b=wQRJuS6iUet3H2jMtoaGmFBXC4WiypJgQEPMBXkE8pqsy/yr+1dWvwH9aE6Fu9q1Qy 1JefyktxIUqpH/kZ00TBBwyw2XjOs33IDI/Rm4VbDGqF+unTDy8Txws1kZ59Fpe3s4Xn bDMwcEnPYC+S0OqhUO27R6R8hymBLHN1gTaw1m4WNChsTXuLtIjerByn5DKtbh8obyuc fvxdHD2q545hrXtZ0UdPDGlOQJQkzSqsZt+xVyY79xvJNSd5vDFyqcyJkwuyAkx7gRdc ghG+oeF1FRSkgSIbRtfGuQ/Paryb01P6bpZYlFGNwTv64eKMpW9zptPAlCV/ZUaYKr3S LuBA== X-Received: by 10.152.148.164 with SMTP id tt4mr42011945lab.28.1358173827895; Mon, 14 Jan 2013 06:30:27 -0800 (PST) Original-Sender: Vasiliy Kulikov Content-Disposition: inline In-Reply-To: <20130114140334.GA29049@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2576 Archived-At: On Mon, Jan 14, 2013 at 09:03 -0500, Rich Felker wrote: > On Mon, Jan 14, 2013 at 12:45:27PM +0400, Vasily Kulikov wrote: > > In musl libc it can be implemented as -DI_WANT_TO_DETECT_GCCISMS. > > At the very least, this would have to be a macro in the reserved > namespace. However, I'm skeptical of using musl as a tool for checking > this, especially since the check only works on 64-bit systems and does > not help the compiler produce a warning/error, but only causes random, > hard-to-diagnose crashes. It looks like cppcheck is adding (or has > already added?) a test for incorrectly passing NULL to variadic > functions, which is probably where the check belongs. My thought related to this specific bug was a bit more complex: 1) on each call of a variadic function save the list of all types 2) on each call to va_arg(ap, T) check whether the current argument was pushed as T in the saved list It would catch not only NULL/(void *)NULL, but also int/long or void*/long bugs. Now I see that while it is possible to implement (2) in libc redefining va_XXX() macros, but it looks like (1) has to be implemented in compiler. So, yeah, it is not a musl issue. Thanks, -- Vasily Kulikov http://www.openwall.com - bringing security into open computing environments