More C type errors by default for GCC 14

Eli Zaretskii eliz@gnu.org
Wed May 10 14:19:48 GMT 2023


> From: Marcin Jaczewski <marcinjaczewski86@gmail.com>
> Date: Wed, 10 May 2023 14:41:40 +0200
> 
> Did you even check if the compiler outpost is still correct?

Yes.

> You mention "validations and verifications", do you do the same
> with the new compiler?

Yes.  But that is a fraction of the effort needed when the source
changes.

> If you can't touch code then you SHOULD not upgrade the compiler.

As I tried to explain, this is not really possible, unless the entire
system is also kept without any changes, which is also impossible,
because hardware gets old and needs to be replaced, and newer hardware
doesn't support old systems.

> Any big project (like Linux) shows these two rules are critical,
> there were multiple cases of security bugs caused by subtle change
> in behavior of the compiler.
> Compiling very old code is lability if nobody knows how it should work and
> nobody maintains it. Who can give you guarantee that the result is correct?
> Very old programs should even by default reject new compilers by default until
> someone does not check if it correctly compiles on new compilers.

This is all true, but the same problems exist even if the programs
don't use outdated C dialect.  So these issues are independent, almost
orthogonal to the issue at hand.


More information about the Gcc mailing list