zaks.anna added a comment. > In this checker, I give warnings for values which are both tainted and were > also not checked by the programmer. So unlike GenericTaintChecker, I do > implement the boundedness check here for certain, interesting constructs > (which is controlled by the critical option). GenericTaintChecker focuses > purely on taintedness, almost like a service for other checkers. I've added a > new rule to it, improving the taintedness logic, but I felt mixing the bound > checking logic into it would make the two ideas inseparable.
I'd like to step back a bit. In my view, the taint implementation should consist of three elements: 1. taint source 2. taint sink 3. cleansing rules I always considered the taint analysis in the analyzer not fully implemented because #3 was missing. It sounds a lot like non-"dirty" scalars would be the same as values that went through cleansing - they should be considered not tainted anymore. Now, are cleansing rules checker specific or generic? If they are generic, these rules should definitely be part of GenericTaintChecker and every checker using taint would utilize them. WDYT? (We can talk about the array bound checking part separately.) https://reviews.llvm.org/D27753 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
