[PATCH] D53974: [clang-tidy] new check: bugprone-too-small-loop-variable
Jonas Toth via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sun Nov 11 10:10:11 PST 2018
JonasToth added a comment.
>> I would be very interested why these false positives are created. Is there a way to avoid them and maybe it makes sense to already add `FIXME` at the possible places the check needs improvements.
> voidForLoopFalsePositive() and voidForLoopFalsePositive2() test cases covers most of the false positives found in LibreOffice.
I would not consider them as full false positives, the constants that are created allow to filter more, but type-based the diagnostics are correct. So I think that is fine. If the constants would be a big value, the check does find a real problem.
> I am fairly concerned the example with unsigned use for container iteration are not false positives, just examples of bad happenstance code which never breaks under real life applications due to uint32_t being good enough but is actually not type-safe.
> Those examples that I kept in my quote are especially bad and should be fixed eventually...
clang-tidy is not about finding _only_ bugs, but find patterns that can be problematic but are not in every instance (therefore `bugprone-` and not `bug-`).
`uint32_t` does not span the whole memory-space for current hardware and a `std::string` can have more then `uint32_t::max` elements. Diagnosing this is valid.
Containers where `uint32_t::max * sizeof(element_type) > size_t::max` could be filtered for normal iteration over the container. I would consider it still a bugprone pattern.
rCTE Clang Tools Extra
More information about the cfe-commits