From owner-freebsd-hackers Wed Jul 31 21:59:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA27775 for hackers-outgoing; Wed, 31 Jul 1996 21:59:40 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA27768 for ; Wed, 31 Jul 1996 21:59:37 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id EAA20168; Thu, 1 Aug 1996 04:59:05 GMT Date: Thu, 1 Aug 1996 13:59:05 +0900 (JST) From: Michael Hancock To: David Leonard cc: hackers@freebsd.org Subject: Re: kernel assertions (Rev. 1) In-Reply-To: <199608010347.NAA13864@foxtail.dstc.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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/ >