[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Derek Snider]

>From Alex, May 1, 2001 8:24 AM
> On Mon, 30 Apr 2001, Derek Snider wrote:

>> I know how to write clean bug-free code.
 
> There was an interesting debate about this on comp.security.unix
> last week.  I won't rehash it here, but suffice to say, the general
> feel was that one or two people claimed that they could write
> bug-free code and had scripts/programs/etc that would find any bugs
> that they happened to write when sleepy.  The rest questioned this
> and asked for the programs so that they could help everyone.  The
> 'bug-free' people seem to have since vanished.
 
I too would be interested in a script that finds bugs for me ;)

First steps to writing bug-free code are:

  1) Know what you're doing.
  2) Plan out what you're going to do before you start coding.
  3) Take your time while coding.
  4) Take time to read over your code.
  5) Compile with all warnings on.

I find that most of my bugs came from being rushed, and making
changes.

It's usually the "quick change" that your boss wants you to do that
introduces a bug.

The most common memory problems come from using uninitialized pointers
and not freeing dynamically allocated memory.

Fortunately most compilers warn on using uninitialized variables...
...if you have that warning turned on.  Make sure that you do.


> I've used Purify on the VieMud code (it choked rather
> catastrophically on the stock DikuMud code), and managed to actually
> find 6-7 small memory leaks that I had never noticed previously.
> Little leaks that only leaked a few bytes here and there, but it
> explained why our memory image had been slowly growing, even if
> nobody was online.
 
> It also found a few out of bounds reads that were on pieces of code
> that did not check on errors and whatnot.  As a whole, I would not
> say that Purify debugged my code at all, but rather, I learned a
> number of ways to protect myself in the future from such errors so
> that these situations (hopefully) wouldn't arise again.

Finding memory leaks and out of bounds reads sounds useful to me :) No
debugger is going to debug logic errors.  It's memory related problems
that plague most C/C++ programmers.

Some memory leaks are difficult to assess.  MUD programmers could
learn a lot from other servers, such as Apache, as far as memory
allocation/deallocation goes.

Apache maintains separate memory pools for different purposes.
There's a pool that gets freed at the end of each request so that your
module doesn't have to worry about freeing memory in that pool.

In DikuMUD we could think of the main mud (pulse) loop as an Apache
request, and have a pool of memory that gets cleared at the end of the
loop.  All temporary allocations could be freed at this point, and you
wouldn't have to worry about freeing any temporary variables inside
individual functions.

Some programmers may scoff at temporary memory pools, but when you're
working on a large project with many programmers, it can give you some
peace of mind.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev