Date: Tue, 30 Jul 1996 12:59:24 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Tony Kimball <alk@think.com> Cc: hackers@freebsd.org Subject: Re: kernel assertions Message-ID: <Pine.SV4.3.93.960730124657.3927B-100000@parkplace.cet.co.jp> In-Reply-To: <199607300256.VAA28307@compound.Think.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960730124657.3927B-100000>