(offtopic: Purify and Valgrind) Re: [Coin-discuss] Purify UMR CoinFactorization::pivotOneOtherRow

[Brian Borchers]

>Neither should flag it.
>foo should be initialized to 0.

Sorry, bad example.  Remove the "static" and make foo a regular
variable within a function.  

The point is that it's not on the heap, and malloc() was never
involved.  valgrind will still check that the variable has been
initialized by your code before it is accessed.  To do this, valgrind
maintains a status bit for every byte of memory on the stack and in
the heap.  For every memory read or write, it checks and/or updates
the status bits.

Note that I've been talking about the "Memcheck" option within valgrind.
If you just use "Addrcheck", you get a debugging malloc() that does
checks very similar to those done by Purify.  
 
The valgrind user manual at 
 
  http://valgrind.org/docs/manual/manual.html
 
Has a very clear explanation of the kinds of bugs that can be found by 
Memcheck and Addrcheck.  It also provides an explanation of how valgrind
works, including:

>Your program is then run on a synthetic CPU provided by the Valgrind
>core. As new code is executed for the first time, the core hands the
>code to the selected tool. The tool adds its own instrumentation code
>to this and hands the result back to the core, which coordinates the
>continued execution of this instrumented code.
>
>The amount of instrumentation code added varies widely between
>tools. At one end of the scale, Memcheck adds code to check every
>memory access and every value computed, increasing the size of the
>code at least 12 times, and making it run 25-50 times slower than
>natively. At the other end of the spectrum, the ultra-trivial "none"
>tool (a.k.a. Nulgrind) adds no instrumentation at all and causes in
>total "only" about a 4 times slowdown.