apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: APR, asserts, policy
Date Mon, 04 Jun 2001 23:49:34 GMT
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

View raw message