6 ms·

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3F https://wiki.gentoo.org/wiki/

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3F https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... 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).

rwmj 2y ago
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).
- mid-kid 2y ago
  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.
  - mikepurvis 2y ago
    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.
    - withzombies 2y ago
      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.
    - mid-kid 2y ago
      You're right, but it's also significantly more inconvenient.
  - cozzyd 2y ago
    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.
    - Phyx 2y ago
      -std=gnu98 works. ie explicitly telling it your code is not modern C.
      - mid-kid 2y ago
        The new flags apply regardless of -std value, as does -fno-common
        Phyx 2y ago
        Uhh no they don't, and it's explicitly documented under https://gcc.gnu.org/gcc-14/porting_to.html 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.
dooglius 2y ago
Very easily worked around with -Wno
- sqeaky 2y ago
  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.
  - mid-kid 2y ago
    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.
  - dooglius 2y ago
    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.
emidln 2y ago
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.
- ho_schi 2y ago
  CPP2/cppfront: https://github.com/hsutter/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.
  - pjmlp 2y ago
    It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.
    - ho_schi 2y ago
      A wannabe replacement by…Herb Sutter. I dare to differ.
      - pjmlp 2y ago
        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.
jcranmer 2y ago
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.
- hulitu 2y ago
  > 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.
  - gizmo686 2y ago
    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
- mid-kid 2y ago
  Plenty of software broke as a result of these flags, gentoo has a tracker here: https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=1 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.
wiseowise 2y ago
Good. Long overdue.
PKop 2y ago
>enables a few -Werror flags by default Presumably they can then be disabled when needed yes? Sounds like a better default.
fl0ki 2y ago
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.

rwmj 2y ago

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

mid-kid 2y ago
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.
- mikepurvis 2y ago
  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.
  - withzombies 2y ago
    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.
  - mid-kid 2y ago
    You're right, but it's also significantly more inconvenient.
- cozzyd 2y ago
  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.
  - Phyx 2y ago
    -std=gnu98 works. ie explicitly telling it your code is not modern C.
    - mid-kid 2y ago
      The new flags apply regardless of -std value, as does -fno-common
      - Phyx 2y ago
        Uhh no they don't, and it's explicitly documented under https://gcc.gnu.org/gcc-14/porting_to.html 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.

dooglius 2y ago

Very easily worked around with -Wno

sqeaky 2y ago
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.
- mid-kid 2y ago
  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.
- dooglius 2y ago
  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.

emidln 2y ago

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.

ho_schi 2y ago
CPP2/cppfront: https://github.com/hsutter/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.
- pjmlp 2y ago
  It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.
  - ho_schi 2y ago
    A wannabe replacement by…Herb Sutter. I dare to differ.
    - pjmlp 2y ago
      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.

jcranmer 2y ago

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.

hulitu 2y ago
> 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.
- gizmo686 2y ago
  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
mid-kid 2y ago
Plenty of software broke as a result of these flags, gentoo has a tracker here: https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=1 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.

wiseowise 2y ago

Good. Long overdue.

PKop 2y ago

>enables a few -Werror flags by default Presumably they can then be disabled when needed yes? Sounds like a better default.

fl0ki 2y ago

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.