Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 19338 invoked by uid 500); 4 Jun 2001 19:11:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 19324 invoked from network); 4 Jun 2001 19:11:42 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to trawickj@bellsouth.net using -f Sender: trawick@bellsouth.net To: Subject: Re: cvs commit: apr-util/include apr_md4.h References: From: Jeff Trawick Date: 04 Jun 2001 15:08:34 -0400 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N "Sander Striker" writes: > Oops, sorry. I was thinking from the library point of view > where all errors should be handled. If the policy is segfaulting > when NULL pointers are passed that makes sense to me. > > However, I would suggest putting in something like: > > #ifdef APR_MD4_DEBUG > assert(context); > #endif I'm got opposed to asserts in general, but I wonder what we'd achieve with one here. I would think that without the assert we still die and the problem should be diagnosable from a core dump. With the message from such an assert from some random program somebody still has to go find the source code to apr-util and see what the assert means. The assert doesn't tell how they got to that point so the core dump is still required to debug it. And we get the core dump for free. -- Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...