Date: Mon, 9 Feb 1998 18:23:46 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Eivind Eklund <eivind@yes.no> Cc: Eivind Eklund <eivind@FreeBSD.ORG>, FreeBSD Hackers <Hackers@FreeBSD.ORG> Subject: Re: DIAGNOSTICS and DEBUG LOGGING (was Re: cvs commit: src/sys/conf options) Message-ID: <Pine.SV4.3.95.980209174124.1787A-100000@parkplace.cet.co.jp> In-Reply-To: <19980209091644.21614@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Feb 1998, 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. > 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. Ok. My initial brief glance at the code I saw it as a way to have light-weight invariants that didn't need a function to check the invariant. After thinking about it, although I could do this in the framework you describe there would probably be little value in doing so. So getting back to your definition, if we had a small subsystem/module that could be implemented in a single file we could have a static check_invariant() for the module within #ifdef _INVARIANTS. For larger subsystems/modules where the check_invariant() is invoked from many files we would use INVARIANT_CODE around the mysubsystem_check_invariant(). I guess this should be documented under man style. Mike > Eivind. > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F, 2-5-12 Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 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?Pine.SV4.3.95.980209174124.1787A-100000>