PreStmt and PostStmt callbacks for OffsetOfExpr are necessary to implement Cert ARR39-C: Do not add or subtract a scaled integer to a pointer. And should I define the offsetof macro in clang/test/Analysis/Inputs/system-header-simulator.h? Or, like clang/test/Analysis/malloc-sizeof.c, use #include <stddef.h>?
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 14025 Build 14025: arc lint + arc unit
Event Timeline
Hello Henry,
The patch looks reasonable. I think it can be landed after comments are resolved.
lib/StaticAnalyzer/Core/ExprEngine.cpp | ||
---|---|---|
1497 | Could you C++11-fy this loop? | |
test/Analysis/offsetofexpr-callback.c | ||
3 | Answering your question, we should put the declaration into system-header-simulator.h. | |
7 | This decl seems unused. Should we remove it? |
The patch seems correct, but i suspect that your overall approach to the checker you're trying to make is not ideal. offsetof returns a concrete value (because, well, symbolic offsetofs are not yet supported in the analyzer), and even if you see the concrete value, you'd be unable to track it, because when you get another concrete value with the same integer inside, you won't be able to easily figure out if its the same value or a different value. My intuition suggests that this checker shouldn't be path-sensitive; our path-sensitive analysis does very little to help you with this particular checker, and you might end up with a much easier and more reliable checker if you turn it into a simple AST visitor or an AST matcher. Just a heads up.
- Use C++11 range-based for loop to traverse ExplodedNodeSet.
- Define the macro offsetof in system-header-simulator.h.
This is a very useful suggestion, many thanks, Noq! Path-sensitive is really a bit too heavy for this checker.
@NoQ Sorry to bother you again. It seems that this patch is useless to analyzer temporarily, if you think so, I will abandon it : ).
All right, i guess we already do have a pair of callbacks for IntegerLiteral and it doesn't hurt, especially because here they'd eventually be actually useful. I think it should land, just to make it easier to add the actual support later.
Could you C++11-fy this loop?