[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130109144712.GY20323@brightrain.aerifal.cx>
Date: Wed, 9 Jan 2013 09:47:12 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: NULL
On Wed, Jan 09, 2013 at 03:42:07PM +0100, Luca Barbato wrote:
> On 09/01/13 12:02, John Spencer wrote:
> > 2) change musl so it is compatible with those apps. this would mean:
> > #if defined(__GNUC__) && defined(__cplusplus__)
> > #define NULL __null
> > #elif defined (__cplusplus__)
> > #define NULL 0
> > #else
> > #define NULL (void *) 0 /* for C code */
> > #end
> > this change is the easiest solution: any problem will be magically fixed.
>
> I'm not sure if there is a way to warn properly at compile time for that
> specific usage.
__attribute__ ((sentinel)) may be used. Adding this to the appropriate
gtk headers (even just as a temporary debugging measure if it's not
desirable permanently) would catch all the bugs calling gtk variadic
functions.
> IMHO going with 2+3 is the only safe way to grant musl more support
2 is not appropriate as written (it's more complexity, and ugly, and
in multiple locations). 3 already exists; it's called GCC.
If we decide something is needed at the musl level, in my opinion the
only acceptable solution is just replacing 0 with 0L unconditionally.
Actually I'd like to remove the special-case for C++ and make NULL
_always_ be defined to 0 or 0L, but I worry too many people would
complain...
> I wonder why in the hell C++ can't use the (void *) 0 definition or
> equivalent.
Because then char *s = NULL; would be a constraint violation.
Rich
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.
