Use a more optimal data structure to represent taint propagation rules. There is no change in the checker's behavior.
Clean up the code.
Details
- Reviewers
gerazo xazax.hun Szelethus a_sidorin dcoughlin george.karpenkov NoQ - Commits
- rG2a5fb1252e2d: [analyzer] NFC: GenericTaintChecker: Revise rule specification mechanisms.
rL352572: [analyzer] NFC: GenericTaintChecker: Revise rule specification mechanisms.
rC352572: [analyzer] NFC: GenericTaintChecker: Revise rule specification mechanisms.
Diff Detail
- Repository
- rC Clang
Event Timeline
If you don't mind, please submit diffs with full context (diff -U99999 or something alike depending on what you use). It makes it much easier to review patches. Also the formatting looks really off in some places where 4 spaces are used. Also another nitpick, nested statement ifs should have the statements within them aligned without adding another indentation level for every line break within the statement, also in case below dyn_cast_or_null may eliminate a need for an additional check in which case you can just use && instead.
if ((D->getName().find("stdin") != StringRef::npos) && D->isExternC()) if (const PointerType *PtrTy = dyn_cast<PointerType>(D->getType().getTypePtr())) if (PtrTy->getPointeeType().getCanonicalType() == C.getASTContext().getFILEType().getCanonicalType()) return true;
Also, is there a reason for pulling in <utility> here?
Could you please reupload with full context? :)
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
Hmm, I find the revision title and summary a little vague -- I'd expect a revision called "Refactoring" not to feature any funcitonal change, yet you changed how variadic functions are handled. Please
- Keep purely formatting changes to your earlier revision, and rebase this patch on that
- Edit the revision title and/or summary about what your patch does,
- If it features any change in the checker's behavior, include tests.
lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp | ||
---|---|---|
127 | typo: marks | |
134–139 | I like this a lot! Call sites look very nice. | |
145–158 | In-class method definitions are implicitly inline -- could you please remove them while we're cleaning up anyways? :) |
Hi, thanks again for looking into this! I have a single piece of doubt that this doesn't change the behavior (the comment about pread), but other than that, this diff is good to go, in my opinion.
lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp | ||
---|---|---|
209 | llvm::ArrayRef has a fancy feature: it can be constructed not only from an initializer list, but also from a single element. This could have allowed skipping {} in these constructors when there is just one value in the list. That's what i would have done, but i guess it's up to you to decide which approach is prettier. | |
221 | Now pread doesn't produce a tainted result when only the buffer is tainted but other arguments are not. Is it a functional change? I guess we should be able to add tests for it. You can also commit this patch with {0, 1, 2, 3} and remove 1 in the next patch that also adds a test. | |
461–462 | auto here as well? | |
462–463 | The more natural way to write this is ArgNum >= CE->getNumArgs(), as opposed to ArgNum < CE->getNumArgs() which is the usual boundary when dealing with arrays that start at 0. | |
481–482 | auto here as well? |
Is it ready to land?
lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp | ||
---|---|---|
209 | Those who don't know that feature will be confused. I should make changes in the constructor to support it. I'm going to leave it. | |
221 | I changed it to {0, 1, 2, 3}. I don't want to make any change in the behavior in this patch. I think who made it use InvalidArgIndex because the previous implementation wasn't expressive enough. |
typo: marks