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

List:       freebsd-hackers
Subject:    Re: kernel assertions
From:       Michael Hancock <michaelh () cet ! co ! jp>
Date:       1996-07-29 18:04:16
[Download RAW message or body]

On Mon, 29 Jul 1996, Poul-Henning Kamp wrote:

> >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.
> 
> I like this idea.
> 
> How about:
> 
> in <sys/cdefs.h> we put:
> 
> 	#if defined(DIAGNOSTIC) || defined(WITH_ASSERTS)
> 	#define ASSERT(cond, expl) if (cond) panic expl ; else ;
> 	#else 
> 	#define ASSERT(cond, expl) /* nothing */
> 	#endif

I think it's better to have ASSERTs on by default.  When a stable snapshot
is identified performance people can turn them off with something like
NO_KERN_ASSERTS.
 
You could also have the preprocessor generate the filename and line
number.

> 
> In our code:
> 	void
> 	foo(char *buf, int i
> 	{
> 		ASSERT(buf,("foo(%p, %d): buf is zero",buf,i));
> 		...
> 	}

Even a simple ...

	ASSERT(buf, "Buf is zero");

would be very beneficial.

There are other types of assertions, but I've found that the parameter
checking assertions helped us spot around 80% of the problems found by
assertions.

The others types include:

func decl ( arg decl )

	[Argument  assertions]

	<Real code>
	<I don't have to say, if param1 and param2, etc. etc.>

		[embedded assertions]
	</Real code>

	[Return value assertions]

Since the primary benefit was in the Argument checks we often just made
the Return value assertions just comments.

The embedded assertions were invariants that we needed to check for in
more complex code.

Thorough checks should probably be done as it is now with the DDB stuff
as I've seen in a few places.

#ifdef DDB
	Do thorough check()
#endif



#ifdef DDB
<Function code for "Do thorough check">
#endif


--
Mike Hancock

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