RedDocMD added a comment. > It's important to realize that with pure static analysis it is absolutely > impossible to reliably report a bug more severe than dead code. Any form of > static analysis only ever finds code that doesn't make sense. It cannot make > assumptions about how often the code is executed in practice or how severe > and impactful the bug is to the users of the program under analysis. When we > report anything that doesn't directly scream "dead code", like null > dereference, we're still always implicitly saying "This code doesn't make > sense because it either has dead parts or _____". In fact we should probably > do a better job at managing expectations because users do become upset when > we promise them use-after-frees but in reality only find dead code that > "would have caused use-after-frees if it was ever run".
Tbh, given how loose of a memory model we are dealing with (at its worst, it is the C memory model), I think the static-analyzer does a great job at detecting what it possibly can. As for the user's expectation, I think we just need to wait for more adoption of the static analyzer. Then users will know exactly what to expect (we do not yell at the C++ compiler for not preventing use after delete, we do not yell at the Rust compiler for not allowing mismatching lifetimes - we know what to expect, and just work with that). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97183/new/ https://reviews.llvm.org/D97183 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
