Date: Mon, 9 Feb 1998 13:07:07 +0100 From: Eivind Eklund <eivind@yes.no> To: Richard Wackerbarth <rkw@dataplex.net> Cc: Eivind Eklund <eivind@yes.no>, Michael Hancock <michaelh@cet.co.jp>, FreeBSD Hackers <Hackers@FreeBSD.ORG> Subject: Re: DIAGNOSTICS and DEBUG LOGGING (was Re: cvs commit: src/sys/conf options) Message-ID: <19980209130707.03437@follo.net> In-Reply-To: <l03130304b1049a4c285d@[208.2.87.4]>; from Richard Wackerbarth on Mon, Feb 09, 1998 at 05:49:52AM -0600 References: <Pine.SV4.3.95.980209160831.661B-100000@parkplace.cet.co.jp>; <19980209075127.63680@follo.net> <Pine.SV4.3.95.980209160831.661B-100000@parkplace.cet.co.jp> <19980209091644.21614@follo.net> <l03130304b1049a4c285d@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 09, 1998 at 05:49:52AM -0600, Richard Wackerbarth wrote:
> At 2:16 AM -0600 2/9/98, Eivind Eklund wrote:
> >> > _ASSERTS - Enable precondition and other cheap assertions
> >> > _INVARIANTS - Enable invariant/postcondition checking (expensive)
> >> > INVARIANT_CODE - Compile in invariant functions.
> >>
> >> So we have 3 levels of "sanity checking" with increasing levels of cost.
> >> I like it, it's a good fit to how people want to use assertions in
> >> practice.
> >
> >Just to make this perfectly clear (I'm not certain if you got my
> >meaning or not):
> >
> >Enabling INVARIANT_CODE will not add _any_ checks to the kernel.
>
> INVARIANT_SUPPORT
Agreed.
> >Instead, it will add the code that is necessary to enable any checks
> >at will. If INVARIANT_CODE is defined for the entire kernel, then
> >_ASSERTS or _INVARIANTS can be defined for any single file without any
> >compilation trouble, even if _ASSERTS/_INVARIANTS isn't enabled for
> >any other file.
>
> Let me suggest something that I found to work well in developing drivers
> on MacOS. Rather than fill the code with
>
> #ifdef _ASSERTS
> if ((unsigned long)cblockp & (CBLOCK-1))
> panic("Unaligned cblock in cblock_free");
> #endif
>
> how about
>
> ASSERT(((unsigned long)cblockp & (CBLOCK-1)), "Unaligned cblock in
> cblock_free");
>
> Then you can hide the _ASSERTS stuff in a header which defines the
> ASSERT macro and get rid of the clutter in the code.
Well, I thought that was a bit too extreme for FreeBSD ;-) I
personally use a fairly heavy assertion system based on that, along
with extra trace and code-control support. My system is usually a bit
overkill except for large projects; for FreeBSD, it might be perfect.
I'll try to send a description to the mailing-list, and then I'll
write up a new version if people seem interested. I need to get a
freeware version of it some day, anyway; re-writing it each time I
switch employers is getting a bit tedious...
> #ifdef _ASSERTS
> #define ASSERT(X,Y) if (X) panic(Y)
> #else
> #define ASSERT(X,Y)
> #endif
#ifdef _ASSERTS
# define ASSERT(X,Y) do {if (!(X)) panic Y;}while(0)
#else
# define ASSERT(X,Y)
#endif
Notice the support for extra argument, the correct direction for the
assert (an assertion should always be true), and the bracketing to
force correct use of ";", making this a single C-statement after
pre-processing with _ASSERTS both defined and undefined.
Your version will bind an else wrong if used as the front-end of an
if.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980209130707.03437>