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.