From owner-freebsd-hackers Mon Jul 29 20:59:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13927 for hackers-outgoing; Mon, 29 Jul 1996 20:59:36 -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 UAA13920 for ; Mon, 29 Jul 1996 20:59:33 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id DAA04014; Tue, 30 Jul 1996 03:59:24 GMT Date: Tue, 30 Jul 1996 12:59:24 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Tony Kimball cc: hackers@freebsd.org Subject: Re: kernel assertions In-Reply-To: <199607300256.VAA28307@compound.Think.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 29 Jul 1996, Tony Kimball wrote: > 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. If ... else ... > - 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.) REQUIRE1(cond, desc) ENSURE1(cond, desc) (less frequently used) > - Others may be removed unless a debug kernel is being built. (Global > macro candidate, second form.) REQUIRE2(cond, desc) ENSURE2(cond, desc) (more commonly used) > - 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. #ifdef DDB ... #endif I'd settle for Poul's ASSERT, or an ASSERT1/ASSERT2, if people don't like the REQUIRE and ENSURE names. Mike Hancock