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]