This is true but by now distros have fixed most of the breakage and sent the changes back upstream (certainly this is true for Fedora).

Well, yeah, for maintained upstreams. I sometimes need to build older versions of software and simply use unmaintained software, for which these changes are a bit of a pain, along with -fno-common before it.

At a certain point, it's probably easier to build and run the unmaintained software in a container running an OS of corresponding vintage. Obviously that has security ramifications, but hopefully this software isn't facing the internet and being in a container at least means you're on a modern kernel and can isolate things at a port and filesystem level.

Debian is super good for this. Most of their apt mirrors are still up and running, so you can easily download and build software from 2002 if you use the appropriate Debian release to do it.

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.

You're right, but it's also significantly more inconvenient.

it would be nice if they provided a gcc-ancient-compat or something though it's easy enough to create an alias with the correct flags.

-std=gnu98 works. ie explicitly telling it your code is not modern C.

The new flags apply regardless of -std value, as does -fno-common

Uhh no they don't, and it's explicitly documented under https://gcc.gnu.org/gcc-14/porting_to.html in "Turning errors back into warnings".

Futher more every warning Explains why the std value affects them.

Very easily worked around with -Wno

I might be wrong, but it is my understanding that a lot of these warnings deal with undefined or implementation defined behavior and that behavior is changing this release. If that understanding is close, for even some of these, then just suppressing the warnings means the software will behave differently.

My understanding is that these were all existing warnings that were off by default (you needed to pass -Wall to see) that are now displayed by default; I don't see any indication in the patch thread that there were corresponding behavior changes.

Nah, you can override the flags and still will remain working, but you have to be aware of it and figure out how to change the flags of a project properly.

It's great seeing progress made here. C/C++ will never be truly safe languages, but every little bit the compiler can help with is appreciated, esp by those maintaining established codebases.

CPP2/cppfront:

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.

It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.

A wannabe replacement by…Herb Sutter. I dare to differ.

Which is exactly why he pretends to not be a wannabe replacement, as it is politically incorrect to have the chair of ISO C++ to also propose a C++ replacement.

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.

Looking at those flags, several of them are erroring about things that have been deprecated since before I was born. If you're going to complain that it's breaking old code, I have to ask why this code is simultaneously important enough to you to use a modern compiler with modern flags to build it and not important enough to bother changing for 30 years.

> things that have been deprecated since before I was born.

You must be very young.

Breaking compilation is not a sign of maturity. See Rust for details.

Rust is 9 years old. By programming language standards, it is the new kid around the block.

C is over 50 years old.

Python is 30.

Haskell 35

Java 30

Plenty of software broke as a result of these flags, gentoo has a tracker here: https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hid...

As per my own experiences so far, we maintain an older version of GCC for matching GBA decompilation projects, which exhibits compilation errors now.

Good. Long overdue.

>enables a few -Werror flags by default

Presumably they can then be disabled when needed yes? Sounds like a better default.

It says a lot that this document has to include things like this:

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