Re: Crash processing g_object_new arguments

[David NeÄas <yeti physics muni cz>]

On Mon, Nov 09, 2009 at 03:17:24PM +0000, erniew comcast net wrote:
> 0 *is* NULL, in pointer contexts.  In fact, some compilers define NULL
> using
>
>    #define NULL 0
>
> So using NULL instead of 0, by itself, won't necessarily address the
> problem, although it will if the definition happens to be
>
>    #define NULL (void *)0
>
> The problem is that this particular NULL appears in the arguments of a
> function that accepts a variable number of arguments.  The compiler
> therefore doesn't know that any particular argument is a pointer and
> can't perform the proper type conversion.

Technically, you are right (show me a modern system that defines NULL as
plain 0 though).  The C++ people were trying to pretend 0 is a good
substitute for null pointer for years and now they introduce nullptr
(wonder, wonder) because it isn't and it only led to troubles.

I expect the (or some) next C standard to require NULL to evaluate to
something pointer-sized and disallow

#define NULL 0

> Arguably, the real problem is the design of g_object_new(), and another
> way to avoid it is the use of g_object_newv().

While g_object_newv() is better and I typically use it, NULL termination
is a pretty standard and nice vararg idiom.

The real problem is `pointers are integers' from the dark times of C.
Without that everyone would see the need for distinguishing between 0
and null pointer and

#define NULL 0

would be immediately seen as broken.

Yeti