Subject: Re: CCL:malloc etc. on DEC Alpha

From: Jing Kong <[email-masked]>
Date: Mon, 20 Mar 1995 09:14:58 -0400 (AST)

On Thu, 16 Mar 1995, Simon Kilvington wrote:

> Konrad Hinsen wrote:
> > 
> > However, in all cases of malloc()-related crashes I have experienced
> > so far (and that is a large number), the code calling malloc() was at
> > fault. The most typical bug is memory access beyond the allocated space.
> > Some versions of malloc() are quite forgiving if only a few more
> > bytes are used, which is often the case, and this explains why such
> > programs work on some machines but not on others. Another common 
> > way to ruin malloc's data space is to work with undefined addresses
> > (bad pointers in C, or wrong number of subroutine parameters in Fortran).
> > 
> 
> 	a (fairly) easy way to check for writing passed the end of malloc
> blocks is to replace calls to malloc with calls to a routine which claims
> slightly more space than is needed, puts some id characters at the start
> and end of the block eg "MALLOC_BLOCK" or something, and returns a ptr to
> the first byte after the id. Then replace calls to "free" with a routine
> that first checks whether the id characters are still intact. If they have
> changed something has writen before/after the start/end of the block.
> 

You can also check if the array index is out of boundary every time you 
access your array by calling a subroutine instead of going directly 
x[i].  This is essentially objective-oriented programming.  In C++, it 
can be done invisibly by operator-overloading.

Jing