From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2535 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: NULL Date: Wed, 9 Jan 2013 13:18:32 +0100 Message-ID: <20130109121832.GL4468@port70.net> References: <50ED4E45.6050801@barfooze.de> 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 1357733930 25497 80.91.229.3 (9 Jan 2013 12:18:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2013 12:18:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2536-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 09 13:19:07 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 1TsucW-0003gq-NZ for gllmg-musl@plane.gmane.org; Wed, 09 Jan 2013 13:19:01 +0100 Original-Received: (qmail 18388 invoked by uid 550); 9 Jan 2013 12:18:44 -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 18379 invoked from network); 9 Jan 2013 12:18:44 -0000 Content-Disposition: inline In-Reply-To: <50ED4E45.6050801@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2535 Archived-At: * John Spencer [2013-01-09 12:02:29 +0100]: > at this point the issue in evince is not fixed, i still need to > create a patch based on their current git master, subscribe to their > ML, send them the patch and hope that they haven't changed their > mind. i think you are overcomplicating this issue this is clearly a violation of the standard and that's what you should tell to the maintainers: using NULL in the argument of variadic functions is ub both in c and c++ the problem is worse in c++ because it actually breaks code in practice with the usual c++ definition of NULL, in c the usual definition happens to work > so for me, there are 3 options how to deal with issue in the future: > > 1) go into the trouble of debugging all future C++ apps i will port, i think this issue should be catched with automated tools, not debugging: static code analyzer or runtime instrumentation of vararg functions > (as a side note: when i googled for g_signal_emit, i found multiple > bug reports to multiple projects, of which the backtraces showed > exactly the kind of varargs UB that i encountered. > all of them were not fixed, but merely worked around. apparently the > developers of these projects didnt find the real cause of their > bugs. > this is not unlikely, as it is very hard to find out whats going on. > https://bugs.launchpad.net/compiz/+bug/932382 > https://trac.transmissionbt.com/ticket/1135 ... ) may be this should get a bit more publicity, it's an easy to fix bug > 2) change musl so it is compatible with those apps. this would mean: > #if defined(__GNUC__) && defined(__cplusplus__) > #define NULL __null i think this is not needed, you can have a definition in c++ that "happens to work" just like the (void*)0 in c: #define NULL 0L but this is just a workaround, the bugs still need to be fixed (in c++11 we could use nullptr which has std::nullptr_t type which converts to (void*)0 in vararg context, but c++11 is not widely used yet) > 3) create some kind of code analysis tool that will scan C++ code i don't know any good open source static code analyzer for c and c++, maybe the clang based one can do the job i tried splint but that does not catch it catching null pointers in general can be tricky as 0 may be a valid argument to a variadic function and the code analyzer has no way to tell if it's meant to be a pointer or not but if NULL is used without a cast then that's an error both in c and c++ as both languages allow various different definitions of NULL which may have different size and representation in vararg context > i'm welcoming any comments on the issue. i'm especially interested > what the gentoo developers think. i wonder what makes them special :)