[wx-dev] RE: [Python-Dev] NDEBUG in Python.h

Robin Dunn robin@alldunn.com
Mon, 19 Nov 2001 16:37:32 -0800


> [Robin Dunn]
> > I'm wondering if any other extension writers are having problems with
> > this code that was added to Python.h for 2.2?
> >
> > #ifndef Py_DEBUG
> > #ifndef NDEBUG
> > #define NDEBUG 1
> > #endif
> > #endif
> > ...
> > In my case I end up with differences in the expected vs. actual
> > vtanles and so the wrong virtual methods are called followed shortly
> > by a core dump.
> >
> > If I have to I can make changes in my code or maybe in wxWindows to get
> > around this, but it was my understanding that NDEBUG should
> > always be set in the compile options and never in header files to avoid
> > this very problem.
>
> The Windows build has always defined NDEBUG in release builds via compile
> options.  The Linux build never did (via compile option or anything else),
> so release builds on Linux (and presumably all other non-Windows boxes)
> contained code for assert() calls.  The number of assert()s in the Python
> codebase has zoomed since I got commit privileges <wink>, so this was
> getting to be a significant expense.  Guido added the #ifdef business to
> give the non-Windows platforms a release-build speed boost.  I agree it's
> better done via command-line option; that's more work, though, and would
> require fiddling the build process for every non-Windows platform.
>

Okay, since I don't know enough about configure and etc. to submit a patch
I'll try to work around it on my end.

OTOH, it seems like leaving the #define there in Python.h would just be a
problem waiting around to bite somebody else in the butt down the road...
This would be an ugly (but very easy) fix, and would save the next guy from
spending two days pulling his hair out:

#ifndef Py_DEBUG
#ifndef NDEBUG
#define NDEBUG 1
#define Py_UNDO_NDEBUG 1
#endif
#endif
#include <assert.h>
#ifdef Py_UNDO_NDEBUG
#undef NDEBUG
#undef Py_UNDO_NDEBUG
#endif

Or perhaps the #define and the #include <assert.h> should just be moved to a
private header that is only included by Python's .c files and is not meant
for public consumption.

Sorry I don't submit it as an official patch, I don't follow python-dev
enough to know what would be the Right Way to do it that would keep the most
people happy...

--
Robin Dunn
Software Craftsman
robin@AllDunn.com       Java give you jitters?
http://wxPython.org      Relax with wxPython!