GCC 10.1 Released (opens in new tab)

Looking at the categories of warnings it produces, I'm not surprised. When I've used similar tools trying to detect the same things, I also saw false positives. It's probably not an easy set of problems, otherwise we'd have it built-in to more tools and enabled by default.

Sadly, that's typical with static analyzers todays...

Tangential: I think many platforms that GCC supports and the kind of optimisation GCC provides might make it a superior choice for projects. For those developers its exciting. Also if an existing project is using it for a long-time and has not intentions of switching to Clang, for them too this would be interesting.

Clang has it although I've personally never tried it due to the horrible rigamarole of setting it up.

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.

I like not having to run another commercial tool[1] that will likely not be in use whenever I move on to the next project because no one has heard of it.

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.

[1] https://news.ycombinator.com/item?id=22712338

An example to detect use-after-free: https://godbolt.org/z/zhiNLW

Basically this replicates what clang-tidy did

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if you're sure that nobody is going to use the initialized portion. Or having multiple mutable pointers/reference to the same object.

You could do something like that at runtime though, but then you have Valgrind, basically.

That is what Microsoft and Google are trying to do with C++ Lifetime Profile.

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.

I think Rice's theorem means that you can't really do that without restricting/annotating semantics like Rust does.

No need to imagine, It's becoming reality -> https://internals.rust-lang.org/t/c-lifetime-profile-1-0-a-k...

yup zero-width-space is going to a do a number on everyone.

As a non-English programmer who has seen a lot of code not written using English please, god, NO. The mixture of English and other languages identifiers in the external libraries makes me cry.

From a non-english speaking country: I prefer US-ASCII for code. Anything else just obfuscates.

There are lots of other languages that support full UTF-8 in identifiers (e.g, Go) and the non-English-speaking world doesn't take advantage.

Tbh, I mainly shared the example code because I was entertained by the contrast of sophisticated naming and crude approximation. Still, it illustrates that this can come in very handy if used properly.

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).

Thanks, it was fixed already :)

it does not make sense to pair development toolchain versions with operating system versions.

If you are a dev then you can prefer using an LTS flavor of Ubuntu with a PPA for whatever you need to be newer. For important stuff this PPA are provided by Canonical so I run newer kernel and nvidia drivers on an older LTS.

Well, you might want to run a newer/non-lts release via lxd/lxc. It's probably a much better idea than pulling in willy-nilly ppa's.

Just use Fedora, which targets developers.