Re: how does purify work?

Chris F Clark <>
13 Aug 2000 18:54:18 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: how does purify work? (Chris F Clark) (2000-08-05)
Re: how does purify work? (2000-08-05)
Re: how does purify work? (Martin Raabe) (2000-08-05)
Re: how does purify work? (2000-08-05)
Re: how does purify work? (2000-08-10)
Re: how does purify work? (Venkatesha Murthy G.) (2000-08-10)
Re: how does purify work? (Chris F Clark) (2000-08-13)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 13 Aug 2000 18:54:18 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 00-08-027 00-08-053
Keywords: tools

"Venkatesha Murthy G." <> wrote:
> If the intent is to catch leaks, there is one more way - provide an
> implementation of malloc etc that audits allocations, and fool the
> program into using this version of malloc.

This is true. The only need for inserting instructions is to catch
bounds (and uninitialized access) errors. If you are only worried
that you are leaking memory, then a garbage collector will suffice.
It can be built into malloc (i.e. when you run malloc, it looks for
memory leaks) or run independently. For a language like C, the Boehm
collector takes some care to search for pointer puns ignoring them as

There are other errors you can catch without intrusive instrumentation
also. For example, Bounds Checker can catch all sorts of errors using
the Windows API simply by wrapping the Windows routines. "Wrapping"
is the commonly used jargon name for writing a routine that is linked
in place of the routine being instrumented (and which often calls the
original routine to do the work). Thus, if you write a replacement
malloc to check for memory leaks, you would call your replacement a
malloc wrapper (especially if it eventually calls malloc to do the
actual allocation).

Anyway, the only need for intrustive instrumentation (inserting
instructions into the actual code (either source or object)) is when
you are trying to detect faults at the (assignment) "statement" level.
That's because most compilers generate code for simple statements (and
don't implement them by subroutine calls). Anything implemented by
subroutine calls can be checked by wrapping routines.

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. Web Site :
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)

Post a followup to this message

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