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

I rather have no unicode identifiers than insecure identifiers, which don't follow the unicode security guidelines for identifiers.

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.

It might have something to do with a heavy usage of templates in a few files, I don't know.

Clang's autovectorization is better in a few functions I disassembled but otherwise the generated code doesn't benchmark any faster, it's better in some places, worse in others.

   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.

(but as a non english person, I find it very helpful to be able to have unicode in strings)

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.

IIRC there's still an issue with gethostname which must be dynamically linked.

In practice this can be "undefined behavior" like dangling pointers or data races. Maybe the new version of the compiler happens to reorder a couple of instructions (which it's perfectly within it's rights to do) which turns a "benign" race into a crash or an exploitable security issue. Is it your fault for writing these bugs? Sure. But if you're a big organization, and you know you have bugs like this, is this a reason not to upgrade your compiler? Absolutely. All the real world testing you've done on your current binaries has value, and losing some of that value needs to be weighed against the benefits of upgrading.

So if you hit issues, do what you do on every other system which is "installing older Xcode / Visual Studio" ? That would not be an issue at all if the toolchain wasn't vendored as part of the distro, you'd just have something like rustup that allows you to use whatever version of the toolchain your project requires.

> There are a number of features that are specific to the macOS toolchain which make this possible. Take a look at the "-mmacosx-version-min" flag on the macOS compiler. This selectively enables and disables various APIs.

yes ? https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...

> We're talking about Linux here. The Windows toolchain is radically different.

what I'm saying is exactly that the Linux desktop world would be in a far better place if Linux followed the Windows / macOS way of vendoring toolchains.

The only thing that is an actual issue on Linux if you want backward compatibility is glibc which does not have an easy way (AFAIK) to say "I want to target this old glibc version". But that's not the issue for what we are talking about which is "getting newer compilers on a given distro" - Red Hat & derivatives manage this without issue with the various devtoolsets for instance.

The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs.

And that's just for humanities.

The mathematic and physics -literate world, doubly so. Everybody uses pi, theta, sigma (e.g. the summation formula) etc symbols...

> The GNU C++ compiler, g++, has a compiler command line option to switch between various different C++ ABIs. This explicit version switch is the flag -fabi-version.

If you want to target a given distro, you -fabi-version this distro's ABI, just like you set -mmacosx-version-min on mac or set _WIN32_WINNT on windows

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"

https://www.youtube.com/watch?v=EeEjgT4OJ3E

What about with a constrained (not necessarily general purpose) AI with the expertise of Scott Meyers, Andrei Alexandrescu, Herb Sutter and Alexander Stepanov?

Native English-speakers are very familiar with the "English alphabet" but that's irrelevant because we're comparing English words (or phrases) with Greek symbols.

> But both of you seem to disagree on what "literate", "very familiar" and "historically" really mean.

Perhaps, but I'm using standard meanings available from any English dictionary.

> Which is fine, language is not made to be precise - luckily we can use precise symbols where precise meaning matters, not English phrases. For example in math and physics.

You can assign precise meaning to words or phrases as easily as you can to Greek symbols. The two approaches differ in that it's easier for (at least English-speaking) humans to remember words or phrases that relate to or approximate the precise meaning than a random Greek letter (I'm sure someone will demand evidence, but this is hardly an extraordinary claim compared to its inverse) while letters (Greek or otherwise) are more expedient to write by hand.

That's irrelevant. The only aspect that is relevant is that the C++ standard does not define nor assume a standard or even fixed ABI, thus each compiler vendor just goes with the flow.

In some rare cases where a compiler vendor also controls the platform and essentially holds a vertically integrated monopoly, they are in a better position to not break the ABI all that often. Everyone else doing stuff in C++, whether writing programs or libraries or compilers or putting together OS distributions, just faces the music.

You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't bridged by mindlessly stating that GCC and mscv are both compilers.

ABI is the bane of C++. Why are you posting comments on a thread about C++ and the problems created by ABI if you are oblivious to this? The only thing you're managing to do is generate noise and make everyone waste their time with your posts.

> so what makes you think Linux would be any different

Because it is, and at many levels. Just the fact that you are entirely oblivious to this basic fact is enough to convince anyone not to bother with any further replies to this thread.