Aaron Richton writes:
On Sat, 1 Aug 2009, Howard Chu wrote:
OK, that lends some weight to the idea that we have too many assert()s in the 2.4 code...
Or too many Debug()s. To test which, you could make include/ac/assert.h contain just the line "#include <assert.h>", then configure with one but not both of --disable-debug and CPPFLAGS=-DNDEBUG.
Ehhhhh. I understand this from the performance standpoint, but from the usability standpoint, I really like to die fast when something's wrong. Even in full production and under load.
Well, there's assert(we kept track of what's going on) and then there's assert(we obeyed our own calling conventions to this static function). And assert(the pointer we are about to follow is not NULL), which helps explain why a crash happens but isn't usually needed to cause the crash.
Configurable for "I want to benchmark above all else," perhaps, but I would be wary of the removal route.
I'd like something like an assume() macro and an assert() macro, where assume() could be #defined as assert or noop or, if the compiler supports it, a compiler hint:-)