Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Good Programming stops guru |||| and BNF of C++
Message-ID: <27773.278afb0b@kuhub.cc.ukans.edu>
Date: 9 Jan 91 17:14:19 GMT
References: <1806@winnie.fit.edu> <658@tnc.UUCP>
Organization: University of Kansas Academic Computing Services
Lines: 75

> * Check all return values - Most library functions return a special
> value for error conditions.

And pay attention to what the return value should be.  Sometimes a 0
is failure, sometimes -1, sometimes 0 is success, etc.  If using C lib
functions also check errors.  You can use _OSERR, _error, and IoErr()
for more detailed info.  And try to handle errors well.  Some failures
are critical, some aren't.  If you cant open a requester, then use an 
Alert so the user knows what is going on.  An alert will *almost*
always work because it only needs a few 100 bytes.

> * Pay attention to pointer usage - there have been commercially
> released programs which reference a null pointer, and thereby trash
> AbsExecBase.

Another no-no is referenceing a pointer after it has been free, or
range errors scribbling off the end of an array.  On things like an
array always include memory for an extra element to errors of 1 (ie
referecing element index 20 in a 20 element array), or hold a NULL in
a string.

AllocRemember()/FreeRemember() can help with long chains of allocations.
 
Also, when you run AVAIL, it will walk the whole system memory list,
so any errors/corruption will be found.

And when using things like realloc(), ParentDir(), etc (functions that
"swap" data structures), dont assume the new pointer is the same as
the old.

> * There are several good PD system and memory monitors around.  If
> they suit your needs, use them ... Almost all of them will let you
> spot outstanding file allocations, and others are useful for detecting
> the null pointer problem.

Enforcer is good for catching bad pointer refs, but needs a MMU.
Mungwall munges memory around your allocations and all free RAM to
increase the chance that bounds errors or RAM problems will hit
(you cant find a bug you dont have).

> internal tests, and can recover or exit gracefully.  Some of the best
> have an "exit module" which closes files, deallocates memory, and
> closes libraries for the whole program on exit.  Grafting this kind of
> stuff onto an existing program is harder.

This is the way I work.  Have your pointers to things like windows,
screens, etc be global.  Initialize them to NULL, and set them to NULL
when you free them.  Then when your program exits, you can allocate
all that you have freed.

Ie:  struct Window *OurWindow;	/* Static data is NULL by default */

int DoExit(int foo)
{ 
	if (OurWindow) {
		CloseWindow(OurWindow);
	}
	OurWindow=NULL;
}

This way the function can be called anywhere in your program and work 
pretty well.  Also if using C, use the ANSI function atexit() or
SAS/Lattice onexit() to install your function as an exit trap, so it
gets called even if your program aborts beyond your control.

> Wildstar
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  markgood	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~