[ILUG] Looking for a lint clone

[Brian Foster]

  | 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.  the un-writable page scheme
 would never report an address in "the middle
 of a page" (for this example, and assuming
 memset() sets from least to greatest address,
 which is very likely).  also, whilst the sizes
 of the write and the malloc()ed block _could_
 be reported by an un-writable page scheme,
 that seems very unlikely.

  | 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.

 *speculating*, the reason `valgrind' is not
 finding the auto example is because it does
 not know how big the auto array is.

 however, the case still seems slightly odd to me
 since, whilst `valgrind' does not know how big the
 auto array is (and note `-g' is _not_ required by
 `valgrind' albeit I used it in the posted example),
 it should be able to detect overwriting critical
 stack frame data, such as (in this case) the return
 address (at least).  one guess is that that is
 simply not implemented, at least not in the
 version I used?   I can imagine difficult technical
 issues here, but will continue to make the point
 that the pushed return address, at least, should
 _never_ be overwritten whilst the stack frame is
 live, which is well within `valgrind's ability to
 detect (AFAIK).

  | I wonder if the following would be of any help ?
  |  http://sourceforge.net/projects/boundschecking/

 interesting.  never heard of it.  could be useful,
 and does sound like it might detect the main error
 in the auto array case.

cheers!
	-blf-
-- 
Experienced (20+ yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com