Python mymalloc.h bug? (was: Re: Building wxPython)

[Randall Hopper]

Robin Dunn:
 |>NULL is defined as ((void*)0) and cannot be assigned to / compared with
 |>another type without a cast in C++.  As this is C++, I believe they
 |>should be using "0" for assignments and comparisons.
 |
 |I don't know how accurate this is but I've been told that C++ compilers that
 |have NULL defined as ((void*)0) in their headers are the ones that are
 |incorrect, not the code that uses NULL.  The headers are supposed to define
 |it as 0.  Maybe you could try undef'ing it and redefining NULL to be 0 and
 |see what happens?

I think you're right.  However the IRIX headers are correct:

     /usr/include/stdio.h:#define NULL               0L

After a bit of grepping, the culprit seems to be Python (1.5.2):

     /usr/local/include/python1.5/mymalloc.h:

         #ifndef NULL
         #define NULL ((ANY *)0)
         #endif

Including <stdio.h> at the top of helpers.cpp before you include anything
else will work around the problem for that source file, but of course
that's a hack, not a fix.

It appears to me that the right fix is for Python's mymalloc.h, if it must
define NULL (does it?), be updated to be more C++ friendly.  E.g.:

         #ifndef NULL
         #  ifdef __cplusplus
         #    define NULL 0
         #  else
         #    define NULL ((ANY *)0)
         #  endif
         #endif

I'm assuming there's some reason we can't just #include <stdio.h> from 
mymalloc.h (?)

-- 
Randall Hopper
aa8vb at yahoo.com