Mail Archives: djgpp/1997/08/16/03:47:31
Lyle <lpak1 AT NO_SPAMccds DOT cc DOT monash DOT edu> wrote:
Eli wrote:
<snip part of yet another excellent reply by Eli>
> > 1) Make a special version of the program source that doesn't
> > use code from included files, by inserting the contents of
> > these file into the main source file. (If you can guess
> > which inclded files you need to debug, insert only them.)
> > Debug that version with any debugger you fancy. When you
> > have found the bug(s) and corrected them, go back to the
> > original source files and correct them as well.
> >
> > 2) Use ``printf debugging''. That is, insert calls to `printf'
> > in strategic points of the program that will print values of
> > variables which can explain how does the problem happen.
> > Examine the output of these `printf' calls and try to
> > induce what is causing the bug.
> >
> > 3) Try to make a small (100 lines or less) program that
> > exhibits the same behavior, post it to this forum and ask
> > people to tell what's wrong with it.
> It's just that i don't ahve time - and i would really like to compile
> the program in 32 bit. However, i can't waste time trying to debug it
> using 'primitive' methods.
If you can't be bothered to spend time debugging your programs (and #3 doesn't
even require you to debug it, just chop it up) I recommend you give this whole
programming thing up. BTW, DJGPP is not just some magic 32-bit wand that you
can wave over your programs and automagically make them work wonders. It
does take a little bit of time and effort.
Also, IMHO, none of the debugging techniques mentioned are "primitive." The
first is definetly the most powerful, the second the quickest and easiest, the
third, the most reliable. ;)
- Raw text -