Thou shalt have no other gods before the ANSI C standard 1604
Trevor L. Jackson, III
One potential challenge with run-time analysis is ensuring sufficient coverage. It might be very easy to miss bugs that are triggered only on certain code paths. I don't rule out the possibility that one could build a tool that is useful nonetheless, but it might take some work.
A simplistic version of this is simply to run the program with bounds checking enabled during testing, and if any bound is ever violated (during the testing phase), then you've got a pretty good idea that the program is likely to be buggy. Unfortunately, that is unlikely to be enough, because for many buffer overruns, it is not at all easy to come up with the test case that triggers the buffer overrun.
Thou shalt have no other gods before the ANSI C standard 1606
Douglas A. Gwyn How does that work again? I don't see how you can deduce path coverage, given only statement coverage figures. Consider this code snippet: if (a) f1(); else f2...
But, if you can build a tool that detects the presence of code which could write to red memory on some input (potentially other than the input currently being processed), that might address the coverage problem.
Thou shalt have no other gods before the ANSI C standard 1605
Jean-Marc Bourguet Usually I use source-line usage counters, as in the following Makefile target which exploits "ctrace": $(PCFILES...
My favorite research work in this direction is the following paper: Eric Larson and Todd Austin, "High Coverage Detection of Input-related Security Faults", Usenix Security 2003. Personally, I thought this was one of the most exciting ideas in security during the year of 2003. I suspect continued work on some direction like this might well be worth the effort.
Alt Folklore Computers Newsgroups