[ILUG] Looking for a lint clone

[Brian Foster]

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

 `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?

cheers!
	-blf-

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

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