From owner-freebsd-hackers Mon Jul 29 19:55:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA10024 for hackers-outgoing; Mon, 29 Jul 1996 19:55:27 -0700 (PDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA10017 for ; Mon, 29 Jul 1996 19:55:23 -0700 (PDT) Received: from Early-Bird.Think.COM (Early-Bird-1.Think.COM [131.239.146.105]) by mail.think.com (8.7.5/m3) with ESMTP id WAA19246; Mon, 29 Jul 1996 22:55:09 -0400 (EDT) Received: from compound.Think.COM ([206.147.16.34]) by Early-Bird.Think.COM (8.7.5/e1) with ESMTP id WAA08819; Mon, 29 Jul 1996 22:55:04 -0400 (EDT) Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id VAA28307; Mon, 29 Jul 1996 21:56:18 -0500 (CDT) Date: Mon, 29 Jul 1996 21:56:18 -0500 (CDT) From: Tony Kimball Message-Id: <199607300256.VAA28307@compound.Think.COM> To: michaelh@cet.co.jp Cc: hackers@freebsd.org Subject: kernel assertions Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoth Michael Hancock on Mon, 29 July: : 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. Assertions should take different forms in order to support different goals. A single form should not be overloaded to provide all facilities. - There may be some assertions which should never be removed, because they provide protection against catastrophic failures. There is no need for a macro in such cases. - Certainly, some assertions should only be removed when a high-confidence configuration is used, for which utmost performance is pivotal. (Global macro candidate, first form.) - Others may be removed unless a debug kernel is being built. (Global macro candidate, second form.) - Finally, some are of use primarily if not exclusively in active development. These should be defined ad hoc appropriately to the task at hand, and limited in scope. In principle, I personally prefer inline functions, defined static in header files, with #ifdef'd bodies. They can be stepped, for example. But neither ANSI nor K&R C provide inlines, so this is probably not acceptable.