From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2578 Path: news.gmane.org!not-for-mail From: Rich Felker 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 10:14:17 -0500 Message-ID: <20130114151417.GN20323@brightrain.aerifal.cx> References: <20130113174731.GS4468@port70.net> <1358106388.32505.17@driftwood> <20130114061135.GM20323@brightrain.aerifal.cx> <20130114084527.GA4055@cachalot> <20130114140334.GA29049@brightrain.aerifal.cx> <20130114143025.GA12142@cachalot> 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 1358176473 18177 80.91.229.3 (14 Jan 2013 15:14:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 15:14:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2579-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 14 16:14:50 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 1TulkM-0008UD-Cd for gllmg-musl@plane.gmane.org; Mon, 14 Jan 2013 16:14:46 +0100 Original-Received: (qmail 21769 invoked by uid 550); 14 Jan 2013 15:14:29 -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 21761 invoked from network); 14 Jan 2013 15:14:29 -0000 Content-Disposition: inline In-Reply-To: <20130114143025.GA12142@cachalot> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2578 Archived-At: On Mon, Jan 14, 2013 at 06:30:25PM +0400, Vasily Kulikov wrote: > 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. Both require support by the compiler. It's impossible to implement va_arg without a compiler builtin. Traditionally it was done with UB-invoking pointer arithmetic on archs where the arguments are passed on the stack, but even this is invalid and will break under compiler optimizations such as inlining or reordering local vars for cache locality purposes. Also, unfortunately, it's an ABI issue. Making this change would create a completely separate ABI. I think static analysis is really the way to go; unfortunately, it requires some degree of additional markup to specify the argument types contract. Rich