On Tue, Jun 05, 2001 at 01:12:56AM +0200, Sander Striker wrote: > Hi all, > > The assert() discussion seems to have taken place a few times > now, but I still feel the need to vent my thoughts on the > matter. > > To get one thing out of the way beforehand: asserts have no > meaning in production builds. They are simply not compiled in > [well, they become noops]. > The same goes for symbols, effectively rendering a coredump > useless. So lets talk about debug builds and the groups of > programmers, the APR programmers and the application programmers > (ie. the APR users).
Okay, let me clarify my position on this. I apologize for being quasi-abrupt earlier. My argument is that I don't like having production code differ from debug code AT ALL. I want the debug builds to behave almost exactly like the release builds. IMHO, the differences are the compiler optimizations, symbols and debugging information that the compiler itself places in the binaries. The only difference in a release build vs. a debug build is what the compiler does with it. If that is violated (i.e. if you have special DEBUG #defines), then you can encounter the case of not being able to reproduce the release code. I think that is troublesome. That said, I think there are some special cases inside of the pool - the memory management stuff can get so confusing that there is often a need for debug functions or routines. However, these wouldn't be enabled by default for most developers - only those developers explicitly working with the pool code. No one else needs to enable these #defines. The code within the #define for apr_md4, apr_sms, etc. weren't really adding any value in the manner that some of the pool debug stuff does (APR_POOL_DEBUG adds the joined stuff). Okay, that's why I think the #defines for debug-related things are bad. That doesn't necessarily answer the issue with asserts. Why are asserts bad? I believe that in a debug build they aren't of any value - because your compiler should add enough debugging information to allow a debugger to know where something went wrong. I don't see what the assert does for you in a debug build that the debugger can't help you find already. Just let the bad thing happen (i.e. try to dereference a null pointer) and your debugger (if it is worth its salt) will jump to there. Once you see the code, you should be able to figure out what went wrong. There is one set of cases that I think asserts are possibly useful - trying to isolate things that just shouldn't happen and you can't reproduce it, but somehow it does happen. An assert should only be present when you KNOW there is no way in hell that these things can happen and you want to dump core to figure out how in the heck this happened *or* you can't feasibly attached with a debugger with a debug build. Things that might be handled or could be caused by the caller's stupidity don't need an assert. I think when Jeff and Greg Ames were debugging www.apache.org, they used some asserts in httpd in a positive manner. This was because they had no clue how this particular bug happened, so they wanted to dump core immediately to analyze it - they couldn't conceivably wait around with a debugger for the problem to occur. That's where the assert is useful. They came back a few hours later and picked up the core files. Using asserts only when necessary leads to cleaner code (IMHO) that doesn't need to deal with no-ops. If they are no-ops, they shouldn't be there in the first place. As far as a policy goes, I'm not sure of an official one. Since APR is essentially branched from httpd, it really follows httpd policy. AFAIK, httpd has always had this policy. And, there are VERY few committers - I think I might be the exception (maybe not) - who have APR but not httpd access - so most people with APR access are aware of httpd policies. I should have spotted this from the get-go, but it slipped by. My fault. I'm the one who committed it. It's a learning experience for all of us. Don't worry too much. Other people will yell and scream if they find something wrong. That's the beauty of open-source. My $.02. -- justin
