Re: Suggestions for C malloc debugging tool

Joerg Schoen <f81@ix.urz.uni-heidelberg.de> wrote:
: I would like to get some comments about the following idea: A lot of
: trouble in developing C code results from bad memory accesses through
: invalid or uninitialized pointers, through subscripts out of range and
: so on. Unfortunately these errors usually show up much later and are
: hard to track down.


been done. several times, e.g., (for free, as opposed to a commercial
product):


http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html
>Bounds Checking for C


: [This sounds awfully familiar, I'm sure it's been done many times before.
: It's a good idea, would be interesting to hear experience re how well it
: works in practice. -John]


Purify does it by instrumenting the object code, therefore cannot pick
up some types of indexing errors. But it's fast, and useful with a
variety of languages.


Insight++ does it by instrumenting the source code, can pick up
indexing errors based on source semantics. But it's abysmally slow
(2-3 orders of magnitude slower than Purify), and tied to the dialect
of C for which it's written. I'd say it's only useful for embedded
applications, or for toy programs (<10kloc).


The free version cited is more like the latter (uses source semantics,
with a modified version of gcc). There's also a Purify-clone called
'checker' that runs on Linux (I've used all but this one - the
reported robustness is too low to get me interested).


--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey
--

Return to the comp.compilers page.
Search the comp.compilers archives again.