It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).
You must be very young.
Breaking compilation is not a sign of maturity. See Rust for details.
C is over 50 years old.
Python is 30.
Haskell 35
Java 30
As per my own experiences so far, we maintain an older version of GCC for matching GBA decompilation projects, which exhibits compilation errors now.
https://github.com/hsutter/cppfront
I hope we see this in C++26 as optional mode i.e. #safe and #unsafe and same for #impdef or so.
CFront wasn't C, nor Objective-C was C, even though both originally started as macro preprocessors targeting C code generation, and were like Typescript for C.
They became their own thing, after enough user based was won, and nowadays all major C compilers and standard libraries are written in C++, not C.
I usually do this first to make sure the software builds and works, then I try to figure out how to get it working on a newer OS.
Futher more every warning Explains why the std value affects them.
> Only cast if confident it's correct, otherwise investigate more. Casts will silence real problems if incorrectly used.
> Do not assume it is supposed to be an int.
> Do not simply cast to the "other side" of the error. Casts will silence warnings/errors, but that does not mean the cast is correct.
Besides the increasingly well-known footguns of old C code, we're always going to have problems if there isn't an inherent safety culture among the people maintaining open source projects, whether as upstream or a distributor.
Presumably they can then be disabled when needed yes? Sounds like a better default.