More C type errors by default for GCC 14

Florian Weimer fweimer@redhat.com
Wed May 10 13:57:11 GMT 2023


* Thomas Koenig via Gcc:

> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.

Thank you for sharing the Fortran perspective.  I think the C changes
are a bit different.  Most of these fixes are of a localized nature, and
there is always an ugly escape hatch for missing function declarations
(write a prototype declaration right next to the call site).  Most
packages we fixed required a small number of changes, and where
maintainers reacted, they weren't opposed to making the changes (maybe
with one exception).  These changes do not create an ongoing maintenance
burden.

Admittedly, there are some packages where the sheer number of issues
makes patchings things up difficult, or the state (and presumed lack of
use) of a program may make creating patches look like a waste of time.
But in the Fedora corpus, these cases are quite rare.  Popular packages
for which we do not have a migration story yet are ksh, procmail, unzip,
zip.  For the latter three, part of the problem is that it's not clear
to what extent legacy systems (pre-C89, maybe even pre-K&R, without
<stdlib.h> or <stddef.h>) still need to be supported.  These cases are
the exception, though.  In those cases, there could be a strong
incentive to make as few changes as possible (so telling the compiler to
keep accepting these obsolete constructs).

Thanks,
Florian



More information about the Gcc mailing list