[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator
Manas Gupta via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jun 21 18:51:58 PDT 2021
manas added inline comments.
================
Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1395
+
+ if (Min > Max) {
+ // This implies that an overflow has occured as either boundary would have
----------------
vsavchenko wrote:
> I commented on this part previously, you shouldn't get fixated on `Min > Max` because `Max >= Min` doesn't imply that overflow didn't happen (less important) and that the range `[Min, Max]` is correct (more important). Recall one of the examples that I had in that email.
>
> There is an interesting pattern about results that we can use:
> * no overflows happened -> `[Min, Max]` (should be always true)
> * 1 overflow happened -> we need to invert the range, but there are two different cases:
> * `Min > Max`, perfect, that's what we expected -> `[Tmin, Max] ∪ [Min, Tmax]`
> * `Max >= Min`, we overflowed and wrapped the whole range -> `[Tmin, Tmax]`
> * 2 overflows happened on one side -> `[Min, Max]`
> * 2 overflows happened on both sides -> `[Tmin, Tmax]`
>
> You need to think of this problem in terms of what really happens and not in terms of combating with assertions.
I think I agree with you. This pattern (and the code following this pattern) makes much more sense, and easier to follow. I think I will refactor the patch accordingly.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103440/new/
https://reviews.llvm.org/D103440
More information about the cfe-commits
mailing list