On Mar 29, 4:48=A0am, Noob <r...@127.0.0.1> wrote:
> > C applications use pointers. =A0A lot. =A0And it is easy to make a
> > mistake with a pointer, producing an illegalmemoryreference or
> > unwanted program behavior.
>
> cf. Valgrindhttp://en.wikipedia.org/wiki/Valgrind
>
> cf. alsohttp://en.wikipedia.org/wiki/Memory_debugger

Valgrind is pretty good but...

a)  Doesn't catch accesses outside of arrays.
b) Doesn't catch accesses outside of a field in struct.
c) Doesn't catch dangling pointers into dead scopes
   (that storage may be in use for another function call)
d) Doesn't catch dangling pointers into recycled memory.
   (x=3Dnew(..); free(x); y=3Dnew; /* gets same storage x had */; *x=3D /*
bad news */)

Our memory safety check does catch these.

-- IDB

> C applications use pointers.  A lot.  And it is easy to make a
> mistake with a pointer, producing an illegal memory reference or
> unwanted program behavior.

cf. Valgrind
http://en.wikipedia.org/wiki/Valgrind

cf. also
http://en.wikipedia.org/wiki/Memory_debugger

C applications use pointers.  A lot.  And it is easy to make a mistake with 
a pointer,
producing an illegal memory reference or unwanted program behavior.  A real
problem with finding an error with a pointer is that the damage may occur 
long
before any application symptoms occur.  For instance, one can store a value
indirect through a dangling pointer, damaging memory now used for another 
purpose.
A program crash may occur far later than the wild store, making the actual
problem very difficult to find.

The C MemorySafety Checker is a tool designed to catch errors with array
accesses and pointers at the moment the access is erroneous, e.g., for
the example, at the moment of the wild store.

More details can be found at http://www.semdesigns.com/Products/MemorySafety

Ira Baxter, CTO
Semantic Designs