> I disagree. Disproportionately in my career random C and C++ code bases failed to build because some new warning was introduced. And this is precisely because compiler options are so bad in that a lot of projects do Wall, Wextra and Werror.
There is nothing to disagree. It is a statement of fact that there is production software that is not expected to break just because someone breaks a compiler. This is not up for debate. Setting flags like Werror is not even relevant, because that is an explicit choice of development teams and one which is strongly discouraged beyond local builds.
> Also the way undefined behavior is exploited means that you don't really know of your software that worked fine 10 years ago will actually work fine today, unless you have exhaustive tests.
No, not really. There are only two scenarios with UB: either you unwittingly used UB and thus you introduced an error, or you purposely used a feature provided by your specific choice of compiler+OS+hardware that leverages UB.
The latter involves a ton of due diligence and pinning your particular platform, particularly compiler version.
So either you don't know what you're doing, or you are very well aware and very specific about what you're doing.
What you are doing is pushing all responsibility on the user. Which is exactly the ridiculous mindset that continues to make C and C++ software shit. It's like having a lawless society and complaining your shit is getting stolen. You can blame the thieves, but that is pretty stupid way to handle things. Maybe just maybe the environment has a huge impact on how people act. And telling people "lol, this single line of code here is invoking UB in your 100mloc codebase. Too bad that we emptied out the database, removed the backups and launched world ending nukes" is just bonkers insane. In no other human made tool is this acceptable. It's like having a hammer that accept only striking nails with between 13.732 newtons and 13.733 newtons of force if you go over or under it shoots you and your family in the face. "Skill issue lel, just hit it with the right amount of force", no how about you fix your fucking tool so it doesn't shoot me in the face at the slightest mistake.
> There is nothing to disagree. It is a statement of fact that there is production software that is not expected to break just because someone breaks a compiler. This is not up for debate. Setting flags like Werror is not even relevant, because that is an explicit choice of development teams and one which is strongly discouraged beyond local builds.
Those two statements don't mix. You can't claim C++ has "a lot of that" backwards compatibility. And in the same breath blame user when the same compiler flags break their code on a new compiler version. It's not like this is hard. Don't add any warnings to existing container flags. Specify new ones instead. Don't exploit new UB which you didn't in previous version. The C++ just don't really care about maintaining backwards compatibility. They may think they do, but they really don't.
> So either you don't know what you're doing, or you are very well aware and very specific about what you're doing.
I dare say that almost no non-trivial C++ codebase contains no UB at all all scenarios. So you can make the argument that all those people don't know what they are doing. But then you admit that C++ is just not a tool that should be touched by mere mortals.
> What you are doing is pushing all responsibility on the user. Which is exactly the ridiculous mindset that continues to make C and C++ software shit.
Correct, because that's what the C and C++ language standards say. Once the programmer writes code that hits undefined behavior, the standard says that there is no requirement on the compiler and runtime to behave in any certain way. Don't shoot the messenger; the compiler is maximizing its legal exploitation within the language standard. Blame the language standard and petition for change. (See my comment https://news.ycombinator.com/item?id=43539554 .)
> It's like having a lawless society and complaining your shit is getting stolen.
Quite the contrary; the law is written explicitly. The language standard says that something is undefined. You don't get to complain that your shit got stolen if it's undefined. It's like leaving your wallet on the street and complaining that it gets stolen, when there is absolutely no law saying that you should expect your stuff to be untouched when it's not within your private property.
> And telling people "lol, this single line of code here is invoking UB in your 100mloc codebase. Too bad that we emptied out the database, removed the backups and launched world ending nukes" is just bonkers insane.
Sadly, it's not insane. A single erroneous write can corrupt a return address or an instruction, and then the attacker can start a remote shell on your system, and nuke your machine. Not theoretical. When it comes to math, logic, and programming, any single error, no matter how small, has the potential to bring the whole house down.
Or, your program already has routines for formatting your hard drive and launching nukes, and it's protected by one flimsy if-statement. You corrupt the variable that controls that condition, and boom, everything's dead.
I hope you don't find it controversial that one arbitrary write to memory (like `(char)0x123 = 0x456;`) is sufficient grounds that nobody can predict the unbounded consequences of it. I do heavily prefer reads and overflows to be not UB though - like in Java and most other languages that came after C & C++. Again, blame the language standards, not the compiler.
> In no other human made tool is this acceptable. It's like having a hammer that accept only striking nails with between 13.732 newtons and 13.733 newtons of force if you go over or under it shoots you and your family in the face.
Hah, I take it that you're unfamiliar with mechanical engineering. For things like carbon fiber bike frames, every bolt must be tightened to a specific torque or you risk cracking the frame and possibly dying. Like, "the stem bolt must be tightened to 5 to 6 newton-metres; too loose and it'll come undone as you ride; too tight and it can damage the part". Likewise, there are examples of airplane crashes that happened because one component that should've been 1.50 mm was manufactured to like 1.40 mm, caused inappropriate rubbing with another part, caused a fuel line to burst, and you can predict the rest. At least debugging software is hell of a lot easier than debugging physical materials.
> Those two statements don't mix. You can't claim C++ has "a lot of that" backwards compatibility.
You can achieve a lot of backwards compatibility if you write code that is within the language standard and not touch UB!
Also, if you haven't done so already, read up on the notion of the C abstract machine. When the compiler analyzes you code, it doesn't think "oh you're on x86, and the add instruction doesn't trap, so your overflow is safe". No, it thinks, "the C abstract machine says that addition overflow is undefined, so we will assume that in never happens, and simplify any logic as a consequence of that assumption".