Index: [thread] [date] [subject] [author]
  From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 12 Jul 1999 15:42:32 +0200 (CEST)

Re: hacking methods to find out bugs

> On Mon, 12 Jul 1999, Steffen Seeger wrote:
> 
> > > On Sun, 11 Jul 1999 mongoose@ms241739.users.mindspring.com wrote:
> > > 
> > > > Are you sure you're casting the data correctly then?  You mentioned you
> > > > shifted to void* from some_struct* type.  There could be a mistake in
> > > > casting ( like a typo ) where you're casting void* to some_sturct to
> > > > some_struct**.  
> > > > 
> > > 
> > > To make this sure, I've restructured it again last week. Could be that
> > > I've overseen one of this. What's the effecient method to find these bugs?
> > 
> > Strong type-checking. Sounds weird, but this (together with 
> > "gcc -c -W -Wall --pedantic") will help to spot most of the 'stupid' mistakes.
> 
> OK... trying... wow... many many warnings... but the warnings are mostly
> the same:
> 
> warning: ANSI does not permit the keyword `inline'

#ifdef __STRICT_ANSI__
#	define	inline
#endif

> warning: ANSI does not permit the keyword `asm'

asm may be compiler specific, so I would try to have a C-replacement or 
explicitly rely on a particular compiler. However, skip the "--pedantic" which
will help spotting non-ANSI C code, but the other warnings are mostly
soemthing you should check.

> OK... checking if other warnings exists...
> 
> > Second would be sanity checking. Whenever you enter a function, check that
> > the parameters are valid (you should do that for functions exported
> > anyway, however, for internal functions assertions would be a better choice.
> 
> I've added -Wstrict-prototypes at the beginning of the development...

I mean run-time checking here.
 
> > Since I've started to use ASSERTions all over my code, the code 
> > detects itself if a strange things are going on. As they are macros, 
> > just compiling with a different debuglevel removes all debugging code.
> > 
> 
> How can I use ASSERTions on my code?

There are some headers included in the KGI-0.9 snapshoti to be found on
my homepage. Namely kgi-0.9/kgi/include/kgi/debug.h. See the comments there.

It defines macros <meta>_DEBUG(), <meta>_ASSERT() etc, where <meta>
is KRN for kernel code, LIB for library code and APP for application code.
To bind this to a particular application, you have to define some functions
(see kgi/Linux/src/system.c) depending on your preprocessor (if it is ANSI
or GNUCC).

You then just define a debug-level before including debug.h and then use the
macros. E.g.

#define	DEBUG_LEVEL	5
#include <kgi/debug.h>

int internal_library_function(int test, void *data)
{
        LIB_ASSERT(345 <= test);
        LIB_ASSERT(test <= 3456);
        LIB_ASSERT(NULL != data);

	... your code ...

	return EOK;
}


int user_called_library_function(int test, void *data)
{
	if (! ((345 <= test) && (test <= 3456))) {

		LIB_DEBUG(1, "test = %i is out of range.", test);
		return -INVAL;
	}

	if (! data) {

		LIB_DEBUG(1, "data is NULL");
		return -EINVAL;
	}

	return internal_library_function(test, data);
}

> > However, this doesn't guarantee you don't have any bugs, but it
> > makes you to think about the allowed parameters, documents them in the code
> > and gives you a warning if something is wrong.
> 
> OK. Thanks!
> 
> Christoph Egger
> E-Mail: Christoph_Egger@t-online.de


			Steffen

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------
----------------- http: http://www.tu-chemnitz.de/~sse/ggi -----------------

Index: [thread] [date] [subject] [author]