Re: Pointer woes... (int) 0 or (void *) 0 for NULL???

[Joe Buck <jbuck at synopsys dot com>]

>     Here's the problem as far as I can tell:
> 
>     In the egcs distribution is a set of C++ include files that are by
> default installed into /usr/local/include.  Two files (libio.h, and
> streambuf.h) have the following code:
> 
> #ifndef NULL
> #ifdef __GNUG__
> #define NULL (__null)
> #else
> #define NULL (0)
> #endif
> #endif

__null is a non-standard magic cookie for pointer to unknown object.
It appears that it does not work to try to convert it into a pointer
to member function.

I'm not sure that it really was such a good idea.  I think that the
original thinking was to have something that works like (void *) except
that it can be converted to pointers of other types without a cast in C++,
but still not be mistaken for an integer for purposes of overloading,
or in stdargs functions where sizeof(int) != sizeof(void*).

>     That macro is killing me for some reason.  I keep on getting this
> error:
> cannot convert `0' from type `{unknown type} *' to type `void
> (UiCallbackHandler::*)(_WidgetRec *, void *, void *)'
> 
>     However, I can't seem to reproduce it in a small test case.  It may
> be a clash with X of Motif, but I removed the code above and #defined it
> as 0, and it fixed all my ills.  If there's any real interest, I'll try
> to come up with a testcase.

I've never encountered the bug because I have always followed Stroustrup's
advice and used 0 to represent the null pointer.

But if we are going to provide __null, it seems that we have to decide
what it does when used as a pointer to function or member.  It seems that
it should be accepted as if it were 0.