[ILUG] Looking for a lint clone

[Bryan O'Donoghue]

Brian Foster wrote:
>   | Date: Sat, 23 Jul 2005 15:57:45 +0100
>   | From: Bryan O'Donoghue <typedef at eircom.net>
>   |
>   | Brian Foster wrote:
>   |  > oh, b.t.w., if the array is dynamic (e.g., malloc(3)ed),
>   |  > then `valgrind' _does_ spot the error [ ... ]
>   |
>   | This being because valgrind places a non writable page after
>   | each alloc'd similar to ElectricFence presumably ?!
>
>  no.  read the valgrind docs on how it works.
>
>  also, you can see this isn't the case by
>  closely examining the previously-posted
>  diagnostic.  `valgrind' reports a 4-byte
>  write to a 2-byte malloc()ed block in the
>  middle of page.

Yes you are right, about that, I didn't read the output. It's worth
noting though, it *should* be fairly trivial with a non-writable page
based scheme, to tell how much of an overwrite we did, on a given
dynamic alloc....

>   | Unfortunately, it (valgrind) probably can't do that with a
>   | stack frame,  unless someone could think of a very smart way,
>   | to, dynamically replace a procedure prolog at runtime, when
>   | running under valgrind !!
>
>  which ("replacing a proc...") is, broadly,
>  exactly what `valgrind' _does_ do, albeit
>  when the program is loaded (before the
>  program starts execution).  what `valgrind'
>  does is add "instrumentation" to the code and
>  executes the result on a synthetic CPU using
>  AV-enhanced memory.  (the synthetic CPU means,
>  amongst other points, `valgrind' trivially
>  knows the write-size.)  again, the `valgrind'
>  docs contain more details.

You're not groking my input.

For valgrind, since it is a simulated CPU it should be possible to
examine the procedure prolog, noting where variables for a given stack
are created ... flag the number of bytes grabbed... in a table, for
address (0xBLAH) and then noting code that touched memory beyond the end
address of what we took from esp... but, it would probably require
intercepting call instructions (as is done in valgrind  I believe) and
then parsing opcodes subsequent to call instructions to decide *how much
we took* from the stack. Parsing the opcodes like that, would probably
be very slow... mightn't _work_ ... and again mightn't even be the
optimal means of achieving what we want to do.

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