On Mon, Nov 09, 2009 at 03:17:24PM +0000, ern...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
