On Wed, 10 May 2023 at 11:48, Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Wed, 10 May 2023 at 11:40, Eric Gallager <eg...@gwmail.gwu.edu> wrote: > > > > On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote: > > > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: > > >> We are currently using gcc 12 and specifying C11. To experiment with > > >> these stricter warnings and slowly address them, would we need to build > > >> with a newer C version? > > > > > > No, the proposed changes are to give errors (instead of warnings) for > > > rules introduced in C99. GCC is just two decades late in enforcing the > > > C99 rules properly! > > > > > > > > >> What practices might the GCC community recommend to a project > > >> wanting to discover the issues uncovered and slowly address them? I > > > > > > -Werror=implicit-int > > > -Werror=implicit-function-declaration > > > -Werror=int-conversion > > > > > > > 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. > > On the Suse list there was a strong objection to doing that, because > it just prolongs the pain. It means maintainers spend the next three > years dealing with it, fixing the same packages again and again, > instead of just getting it done.
And if you don't want to deal with them all, just use the -fpermissive flag (or however it will be named) to get the old behaviour. I really don't see how dragging this out over **another** three years will help anybody. Florian's already been working on this for years.
