From owner-freebsd-hackers Mon Jul 29 04:59:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA21973 for hackers-outgoing; Mon, 29 Jul 1996 04:59:33 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA21968 for ; Mon, 29 Jul 1996 04:59:30 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id LAA28717 for ; Mon, 29 Jul 1996 11:59:27 GMT Date: Mon, 29 Jul 1996 20:59:27 +0900 (JST) From: Michael Hancock To: hackers@FreeBSD.ORG Subject: kernel assertions In-Reply-To: <199607290924.SAA00390@chiota> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Any comments on introducing an assertion macro for kernel code that panics if the expression is false and does nothing otherwise. It would also be very cool to preprocess it out with something like a -NDEBUG flag. It could be called KASSERT or KERN_ASSERT. Benefits: 1) You write most of your code assuming the parameters are correct. This would get rid of a few if ... then ... else's. 2) You define your function requirements clearly to callers of your function. An example follows below: Original version ---------------- /* * remove the buffer from the appropriate free list */ void bremfree(struct buf * bp) { int s = splbio(); if (bp->b_qindex != QUEUE_NONE) { TAILQ_REMOVE(&bufqueues[bp->b_qindex], bp, b_freelist); bp->b_qindex = QUEUE_NONE; } else { panic("bremfree: removing a buffer when not on a queue"); } splx(s); } KERN_ASSERT version --------------- /* * remove the buffer from the appropriate free list */ void bremfree(struct buf * bp) { int s = splbio(); KERN_ASSERT(bp->b_qindex != QUEUE_NONE) TAILQ_REMOVE(&bufqueues[bp->b_qindex], bp, b_freelist); bp->b_qindex = QUEUE_NONE; splx(s); } This was a simple example but I'm sure it could make code a lot less intricate in other places. Confident performance freaks can preprocess away a few clock cycles. This could add up for frequently called functions. -- Mike Hancock