[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130109121832.GL4468@port70.net>
Date: Wed, 9 Jan 2013 13:18:32 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: NULL
* John Spencer <maillist-musl@...fooze.de> [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 :)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
