Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3B1D253D.34603F6D@algroup.co.uk>
Date: Tue, 05 Jun 2001 19:30:21 +0100
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
Cc: Sander Striker <striker@samba-tng.org>, dev@apr.apache.org
Subject: Re: APR, asserts, policy
References: 
 <Pine.SGI.4.32.0106041737360.16179-100000@armstrong.cs.virginia.edu>
 <JLEGKKNELMHCJPNMOKHOAEGNDPAA.striker@samba-tng.org>
 <20010604164933.V11762@ebuilt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Justin Erenkrantz wrote:
> 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.

Clearly it is awkward to maintain but there are good reasons for having
debug only code...

> 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.

Checking for null is not a particularly good reason (unless the
detection without an assert is going to be miles away or rare), but I
would certainly agree that in this case the release and debug code
should be the same (i.e. the assert should not go away when debugging is
switched off, if an assert is required at all).

But here's a couple of examples of where you simply can't have the same
code in release as in debug:

a) "is this object in that pool?" - too slow for production code

b) "is my heap consistent?" - too slow and too big for production code.

> 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.

Precisely so. But these cases should assert in production code, too (so
long as they pass the "not too slow or too big" test).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff