2 ms·

People can and have added extra annotations to C and C++ code for such things. Static analyzers can catch some use-after-free and iterator invalidation bugs at

People can and have added extra annotations to C and C++ code for such things. Static analyzers can catch some use-after-free and iterator invalidation bugs at compile time. Problem is: • They're opt-in instead of opt-out (meaning none of your system libraries or 3rd party dependencies have bothered using them.) • What's been implemented in practice frequently fails to find bugs in relatively simple toy examples (I often confuse myself wondering why I've failed to turn some new bit of static analysis on, when in fact I have, and it's simply failed to catch even my demonstration bug.) • The effective tools, on the other hand, tend to have "false" positives as well. The conclusion I've come to is that to fully solve these problems in C or C++, you'd effectively transform it into a new language. And at that point, you might as well stop pretending that's not exactly what you're doing, and actually create said new language. --- That said, when stuck using C or C++, static analysis and the compiler-specific half measures that are available are worth using, IMO. • https://awesomekling.github.io/Catching-use-after-move-bugs-with-Clang-consumed-annotations/ https://awesomekling.github.io/Catching-use-after-move-bugs-... • https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html • https://clang.llvm.org/docs/AttributeReference.html#lifetimebound https://clang.llvm.org/docs/AttributeReference.html#lifetime... • https://github.com/MaulingMonkey/notes/blob/master/programming/cpp-inspired-by-rust.md https://github.com/MaulingMonkey/notes/blob/master/programmi... • `printf` type checking annotations exist, but don't necessairly work on MSVC. Often sanest to make your legacy logging macros call `printf` in a dead branch to leverage any hardcoded type checking of `printf` Basically everything is a warning that you might consider cranking up to an error, of course.

Someone 3y ago
> The effective tools, on the other hand, tend to have "false" positives as well. That’s true for rust, too, with the difference being that rust won’t compile false positives. I haven’t used rust or recent C++ much, but it wouldn’t surprise me if the false positives that C++ gives had significant overlap with cases where the equivalent rust code would not compile.
- estebank 3y ago
  An example of this could be trying to mutably access disjoint parts of a Vec. The Rust language today doesn't understand that is safe today, because it would require tracking all indices used somehow to verify that the accesses are indeed disjoint. But you can write unsafe code to access those fields, or even better, use Vec::split_at_mut() which uses the unsafe code you'd have to write with the appropriate precondition checks to ensure you can't misuse it in a way that causes memory unsafety.

Someone 3y ago

> The effective tools, on the other hand, tend to have "false" positives as well. That’s true for rust, too, with the difference being that rust won’t compile false positives. I haven’t used rust or recent C++ much, but it wouldn’t surprise me if the false positives that C++ gives had significant overlap with cases where the equivalent rust code would not compile.

estebank 3y ago
An example of this could be trying to mutably access disjoint parts of a Vec. The Rust language today doesn't understand that is safe today, because it would require tracking all indices used somehow to verify that the accesses are indeed disjoint. But you can write unsafe code to access those fields, or even better, use Vec::split_at_mut() which uses the unsafe code you'd have to write with the appropriate precondition checks to ensure you can't misuse it in a way that causes memory unsafety.