[1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...
It does show potential, and I hope it improves in future. Be nice to have a libre version of coverity one day.
Edit: Output from compiling nbdkit upstream with -fanalyzer: https://paste.centos.org/view/8381f926
I've been meaning to formally prove one of our internal "mini libraries" using Frama-C. If we did that then no one would be able to complain about bugs in it :-)
Compiling with clang is much, much slower but it finds interesting errors sometimes. I only had to ifdef out one code section that it couldn’t understand (something about indexing an array with a constexpr function returning an enum class from a template parameter).
It depends on the project, but this one and another project I made work are both 100k lines of C++ and took half a day to setup. It was worth it imo.
In GCC it's a compiler flag. In LLVM it's a convoluted process automated by either an irritating perl/python script (The python one isn't included by default for some reason despite being far more common these days) or AN ENTIRE WEB SERVER TO OUTPUT TEXT (Which thankfully isn't included by default).
I'm sure you could set it up in make but since my projects aren't large scale enough to really need it I can't be bothered, even if it's one of those things you'll probably only need to write once and can just copy and paste ad-infinitum.
clang --analyze --analyzer-output text ...
-% scan-build10 make
scan-build: Using '/usr/local/llvm10/bin/clang-10' for static analysis
...
scan-build: No bugs found.
Biggest advantage I see is it's integrated into the compiler and so sees the same things the compiler does.
Having gcc do this out of the box helps people port their experience/skills with static analysis to other companies.
We already have clang-tidy and I like it too but it's nice to have a fall-back to compare when one produces a strange result. And a bit of competition is always good to have between such projects. And on most big projects it's not like you can just change the build system to use another compiler.
Also I found some interesting cases which valgrind didn't see because it was in an unreachable branch.
Basically this replicates what clang-tidy did
You could do something like that at runtime though, but then you have Valgrind, basically.
Rust supports MaybeUninit<> for the former example, and unsafe raw pointers for the latter. It needs unsafe because these patterns are not safe in the general case and absent an actual proof of correctness embedded in the source code, a static analysis pass can only deal with the general case.
C codebases then follow certain defensive programming customs to avoid reading uninitialized or out of bounds memory, at the cost of some performance. This is the right trade-off in C but, funnily enough, the more restrictive borrow checker has the opposite effect as you can give out inmutable and mutable references with wanton abandon because they get checked for unsafe behavior. It's the same difference as a a gun where the best practice is to keep it unchambered at all times to avoid the risk of a misfire, and a more modern gun with a safety: it's one more thing to think about but it actually smoothes the operation.
This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. It serves the similar purpose as type annotations in function signatures.
> Or having multiple mutable pointers/reference to the same object
Sure you can have that with `unsafe`. And this is a good thing, because multiple mutable pointers to the same object is at best bad coding practice that leads to unsafe code, and you should avoid that in any language, including the ones with GC. Working with codebases where there are multiple distant things mutating shared stuff is a terrible experience.
If a C/C++ version of "borrow checker" could mark such (anti)patterns at least as warnings, that would bring a lot of value.
"Update on C++ Core Guidelines Lifetime Analysis. Gábor Horváth. CoreHard Spring 2019"
What about with a constrained (not necessarily general purpose) AI with the expertise of Scott Meyers, Andrei Alexandrescu, Herb Sutter and Alexander Stepanov?
https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
"Update on C++ Core Guidelines Lifetime Analysis. Gábor Horváth. CoreHard Spring 2019"
https://www.youtube.com/watch?v=EeEjgT4OJ3E
While it might never be Rust like due to language semantics, it is way better than not having anything.
static const int π = 3;
int get_naïve_pi() {
return π;
}
present?(p) // return bool
get!(g) // throw if not found
I rather have no unicode identifiers than insecure identifiers, which don't follow the unicode security guidelines for identifiers.
Of course you can also cause all sorts of mayhem. Even disregarding fun such as GREEK QUESTION MARK looking like a semicolon and zero-width spaces, I probably would not use this feature in enterprise code. Too likely that some tool somewhere (e.g. an alternate compiler?) is KO'd by characters outside of basic ASCII range (which has served us well and will keep doing so).
Nice to see a bunch of C++20 features making it in. Coroutines seems like a big one!
Goes to look at README.Bugs. Holy cow, I don't have time to to check all those places to see if it has been reported already.
One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary.
If you want the latest GCC, that's fine, you're not forced to use the default compiler distributed with your OS. But it doesn't make sense to update the default compiler used in an LTS release. If you want that, then you don't want LTS.
[1]: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/pp...
Surely it's available from here at the very least?
> or any of the mirrors I tried
Seems to be to me?
ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-10.1.0/