Hi Jordy, Overall this looks great. Couple comments:
+ // FIXME: It would be nice to eventually make this diagnostic more clear, + // e.g., by referencing the original declaration or by saying *why* this + // reference is outside the range. Generally we try and enhance bug reports by reporting the details along the path instead of summarizing them all at the end. The apparatus for doing this right now isn't great, but the idea is to use a BugReporterVisitor class that acts as a callback from BugReporter when BugReporter has selected the path to present to the user. You also made the following comment: +// FIXME: This was originally copied from ArrayBoundChecker.cpp. Refactor? I absolutely agree, although I'm fine with a check going in like this first and then refactoring. There is a bunch of logic here with tremendous overlap with ArrayBoundChecker. Perhaps we should build a more generic "out-of-bounds detection" API, and make ArrayBoundChecker a "meta-checker". Not sure. On Jun 29, 2010, at 1:13 AM, Jordy Rose wrote: > Proposed: a new checker that models the evaluation of the string functions > in <string.h> (or at least checks the arguments), both the byte string and > the NUL-terminated string functions. > > Currently I only have it checking memcpy() (and its friends memmove() and > bcopy()), but it does catch both overflows and overlaps. > > (Adding a new checker seems like a big enough change to warrant pre-commit > review!) > > Jordy<CStringChecker.patch>_______________________________________________ > cfe-commits mailing list > cfe-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
