Index:
[thread]
[date]
[subject]
[author]
From: Christoph Egger <Christoph_Egger@t-online.de>
To : ggi-develop@eskimo.com
Date: Mon, 12 Jul 1999 14:45:46 +0200 (MEST)
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'
warning: ANSI does not permit the keyword `asm'
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...
> 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?
> 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
Index:
[thread]
[date]
[subject]
[author]