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]