[ILUG] Looking for a lint clone

[Bryan O'Donoghue]

Brian Foster wrote:
>   | Date: Sun, 24 Jul 2005 16:48:22 +0100
>   | From: Bryan O'Donoghue <typedef at eircom.net>
>   |
>   | Brian Foster wrote:
>   |  > which ("replacing a proc...") is, broadly,
>   |  > exactly what `valgrind' _does_ do  [ ... ]
>   | 
>   | You're not groking my input.  [ ... ]
> 
>  perhaps.  what I am pointing out the scheme proposed
>  seems expensive and may not catch very much.  to wit,
>  consider the routine:
> 
>      void foo(void) {
>         int a;
>         int b[2];
>         int c.
>          ...
>         b[2] = 17;
> 
>  assume, for sake of argument, the three auto
>  variables are laid out on the stack in the order
>  written in the C code:  a at least address, then
>  b[2], then c at greatest address, with no padding
>  in-between.  in that case, &b[2] == &c, and hence
>  the bogus write will not be caught by `valgrind'
>  (because it is a write to a valid location, just
>  accessed by an incorrect source expression).
> 
>  the above example also shows that even if
>  `valgrind' did know the dimensions of the array,
>  it still probably could not catch errors of this
>  sort, since there is nothing in the compiled code
>  to distinguish an array access to b[2] from a
>  proper access to c.   (yes, this is a change from
>  what I said earlier; I now realise that even the
>  dimension data is insufficient, albeit it could
>  help in the original memset(3) example.)


I had a thought... that with a binary compiled with -g, our hypothetical
stack opcode intercept hack might just work , but not without it.

>  `valgrind' does — everyone(?) agrees — know where
>  critical metadata (e.g., return address, and maybe
>  the frame pointer) is on the stack, and hence it
>  _could_ detect overwriting said metadata.  but it
>  isn't, and that is what has me puzzled.  and I am
>  *speculating* it simply isn't implemented?

Hmm, perhaps it would be too slow to graph such information, or perhaps,
there is some non-obvious/tedious reason it's not feasable.

> p.s.  despite this interesting class of examples of
>       errors `valgrind' does not / cannot catch, I
>       still very much recommend it!

I had a half composed mail gushing the wonders of valgrind,gdb, oprofile
 and friends... I agree with you here. Really, I guess we're very lucky,
to have such brilliant tools, valgrind, gdb, oprofile, gcc and friends.

If only I appreciated girlfriends like I appreciate good programming
tools... perhaps more of my pet rabbits would have survived to tell the
tale !


-- 
"I have to return some video tapes" -- Patrick Bateman