Compiler Options Hardening Guide for C and C++

> Sane defaults should be table stakes for toolchains but C++ has "history".

Yes, it has. By "history" you actually mean "production software that is expected to not break just because someone upgrades a compiler". Yes, C++ does have a lot of that.

> All significant C++ code-bases and projects I've worked on have had 10s of lines (if not screens) of compiler and linker options - a maintenance nightmare particularly with stuff related to optimization.

No, not really. That is definitely not the norm, at all. I can tell you as a matter of fact that release builds of some production software that's even a household name is built with only a couple of basic custom compiler flags, such as specifying the exact version of the target language.

Moreover, if your project uses a build system such as CMake and your team is able to spend 5 minutes reading an onboarding guide onto modern CMake, you do not even need or care to set compiler flags. You set a few high-level target properties and you never look at it ever again.

> Yes, it has. By "history" you actually mean "production software that is expected to not break just because someone upgrades a compiler". Yes, C++ does have a lot of that.

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.

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.

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