Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ