Also, I *really* don’t think valgrind could find these errors. Because, see the code, there’s nothing invalid about accessing y[-1]. It’s a valid piece of memory at the end of x[] .. And structs don’t have junk memory between them. There’s nothing actually wrong with the code at all, so it has to be a static check or a run-time bounds check. It can’t be found with valgrind.

I could be wrong here, but .. I’m PRETTY SURE.

-Phil

http://www.bugfighter-soft.com/

and

http://www.microfocus.com/products/micro-focus-developer/devpartner/index.aspx

I’ve also used XCode analyze and that helped me catch another handful of bugs.

Neither of those catch this particular type of bug though.

Valgrind comes pretty close and is worth a try, but I don’t think it would catch that particular case. As far as the compiler is concerned that isn’t actually an error.

If you can find a C interpreter, that might work in a limited scope (like unit tests).

I’ve been using eastl which is nice and streamlined and avoid the allocator complexity of c++, but then again I sort of like stl in the first place. If you’re using something like that you can add rangle checks and track your allocations pretty handily.

Carmack has a blog post about some industrial strength tools, I’m not too familiar with these but they might be worth investigating:
http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

If you want to stick to straight C arrays, since there’s no hooks to instrument the array lookups, the only option I can see is to make some kind of debug macro like CHECK_RANGE(i, data) that you use near suspicious array lookups like that and could use sizeof to figure out the range.

Also, getting in the habit of using size_t instead of int for indexes will help with overflows and negative indexes.

http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page