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
ANN: Memory Safety Checker ... find those pesky memory reference problems in your C code
Started by ●March 28, 2011
Reply by ●March 29, 20112011-03-29
> 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
Reply by ●March 30, 20112011-03-30
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_debuggerValgrind 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