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. @whisperity > 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. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D53974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
