[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    kernel assertions
From:       Tony Kimball <alk () think ! com>
Date:       1996-07-30 2:56:18
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]