Re: More C type errors by default for GCC 14

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]


Eli Zaretskii via Gcc <gcc@gcc.gnu.org> writes:

>> From: Eric Gallager <egall@gwmail.gwu.edu>
>> Date: Wed, 10 May 2023 06:40:54 -0400
>> Cc: joel@rtems.org, David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
>> 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>, 
>> 	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
>> 
>> Idea for a compromise: What if, instead of flipping the switch on all
>> 3 of these at once, we staggered them so that each one becomes a
>> default in a separate release? i.e., something like:
>> 
>> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
>> - GCC 15: -Werror=implicit-int gets added to the defaults
>> - GCC 16: -Werror=int-conversion gets added to the defaults
>> 
>> That would give people more time to catch up on a particular warning,
>> rather than overwhelming them with a whole bunch all at once. Just an
>> idea.
>
> What do we tell those who cannot possibly "catch up", for whatever
> valid reasons?  E.g., consider a program written many years ago, which
> is safety-critical, and where making any changes requires so many
> validations and verifications that it is simply impractical, and will
> never be done.  Why would we want to break such programs?

Upgrading the toolchain is a change which requires validation, surely.

They can then test it at the same time as porting to modern C. Or simply
set the required options (as we're discussing) to allow older,
to-be-rejected constructs.

(It's also not clear to me that they're entitled to a GCC which always
works for them forever. People who like the behaviour of older GCCs
and refuse to change anything about their environment (not necessarily
their code) are able to stick with old versions if they wish.)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]