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

List:       freebsd-hackers
Subject:    Re: kernel assertions (Rev. 1)
From:       Michael Hancock <michaelh () cet ! co ! jp>
Date:       1996-08-01 4:59:05
[Download RAW message or body]

On Thu, 1 Aug 1996, David Leonard wrote:

> This might be a little arcane, but as you haven't yet talked about what
> actual message is emitted, how about going the extra step in 
> readable macros? something a little like this, maybe:
> 
> 	REQUIRE("that bp points to something", bp != NULL);
> 
> 	mod/file.c:123: require that bp points to something
> 
> and
> 	ENSURE( "that the buffer is no longer queued",
> 		bp->b_qindex == QUEUE_NONE );
> 
> 	mod/file.c.124: Failed to ensure that the buffer is no longer queued

This is nice.

> I really like the idea of names such as REQUIRE/ENSURE over ASSERT, but 
> i hesitate at the numbers. 
> But... one could get used to it I suppose. (sounds like a microsoft attitude) 

I don't like the numbers either, but performance matters to a lot of
people.  Especially, the kernel.  I think for practical purposes 3 levels:

	No assertions
	Important assertions
	Important assertions + Specification assertions

are minimally required.  We want important assertions in production
binary, however having complete specifications in the production binary is
too much.  I'm sure many have experienced the pitfalls.

> Looking at it again, I think it would raise the readability (and hence
> learnability/searchability(?)) of the FreeBSD source tree no end! In some ways,
> having to express the predicate that you are trying to ENSURE() essentially
> documents your code better! Unless, of course you
> 
> 	ENSURE( "bp!=NULL", bp!=NULL );
> 
> which I would like to see avoided :)
> 
> 


The problems below just have to be special cased as they are now.

#ifdef DIAGNOSTICS

Do a bunch of stuff including writing helper functions or whatever is
necessary.

#endif

You just have to draw a line somewhere.

The assertions should just be used for the obvious.  The obvious is what
our minds often filter out when looking over the same code for a long
period of time.

Regards,


Mike Hancock

> Other problems I can think of are:
> 
> - side effects of the conditionals
> - conditions that take longer than constant time to be evaluated
> 
> So, sure you can whip up some simple-looking examples of ENSURE/REQUIRE, but
> what about when you end up with something like this:
> 
> 	ENSURE( "nothing in the queue has an invalid buffer",
> 		({ 
> 			thing* x;
> 			for(x=queue->head;x;x=x->next) 
> 				if ( !valid_buffer(x->buffer) ) return 0;
> 			return 1;
> 		}) );
> 
> first, valid_buffer() may have side effects which will alter operation
> if these (expensive) checks are compiled out ,and second, being a linear 
> time check, an interrupt or something may happen in the middle which might
> affect the data structures being examined.
> 
> the long-time problem can be handled with ENSURE2, ENSURE3 and so on, but
> does anyone have a nice way of handling the side-effect problem?
> 
> d
> -- 
> David Leonard                            Project Officer, DSTC
> The University of Queensland             david.leonard@dstc.edu.au
> http://www.dstc.edu.au/~leonard/
> 

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