Date: Mon, 29 Jul 1996 21:56:18 -0500 (CDT) From: Tony Kimball <alk@think.com> To: michaelh@cet.co.jp Cc: hackers@freebsd.org Subject: kernel assertions Message-ID: <199607300256.VAA28307@compound.Think.COM>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607300256.VAA28307>