Comment by dilawar
4 days ago
> So this mode needs to set user expectations appropriately: your code breaking between compiler releases is a feature, not a bug.
Good luck. I feel that the C++ community values backward compatibility way too much for this to succeed. Most package maintainers are not going to like it a bit.
There has been plenty of breakage throughout ISO revisions.
The biggest problem is ABI, in theory that isn't something that standard cares about, in practice all compiler vendors do, thus proposals that break ABI from existing binary libraries tend to be an issue.
Another issue is that WG21 nowadays is full of people without compiler experience, willing to push through their proposals, even without implementations, which then compiler vendors are supposed to suck it up and implement them somehow.
After around C++14 time, it became cool to join WG21 and now the process is completely broken, there are more than 200 members.
There is no guidance on an overall vision per se, everyone gets to submit their pet proposal, and then needs to champion it.
Most of these folks aren't that keen into security, hence the kind of baby steps that have been happening.
Compilers at least allow specifying the standard to target, which solves the ISO revision issue. But breaking within the same -std=... setting is quite a bit more annoying, forcing either indefinite patching on otherwise-complete functional codebases, or keeping potentially every compiler version on your system, both of which are pretty terrible options.
Breaking within the same std, is something impossible to prevent in compiled languages with enough freedom in build.
Even the C ABI many talk about, most of them don't have any idea of what they are actually talking about.
First of all, it is the OS ABI, in operating systems that happened to be written in C.
Secondly, even C binary libraries have plenty of breakage opportunities within the same std, and compiler.
ABI stability even in languages that kind of promise it, is in reality an half promise.
Bytecode, or some part of the language is guaranteed to be stable, while being tied to a specific version, not all build flags fall under the promise, and not much is promised over the standard library.
Even other good examples that go to great efforts like Java, .NET or Swift, aren't fully ABI safe.
16 replies →
Assuming the code is position independent why can't the linker translate the ABI?
4 replies →
I wish the additional proposak that would add Eust like editions with the cpp moduled were expected. So sad it didnt pass.
I don't like that statement (or that whole paragraph) one bit either. My packages breaking between compiler releases is most definitely a big fat bug.
If bounds checks are going to be added, cool, -fstl-bounds-check. Or -fhardened like GCC. But not by default.
Working existing code is working existing code, I don't care if it looks "suspicious" to some random guy's random compiler feature.
I'm kind of with you on the coding-style warning flags. it does really bother me that some opinionated person has decided that the way I use parenthesis needs to be punished.
but I totally disagree with your second point. running code often has real problems with race conditions, error handling, unwanted memory reuse, out of bounds pointers, etc. if a new version of the compiler can prove these things for me - that's invaluable.
I too love those features. Just behind an option, so that existing scripts etc still continue to work.
If many of those features are being added and the flags might add up to become a pain, then even a group flag -f-new-safety-features or whatever.
For many, backwards compatibility == long term employment.