On Wed, May 10, 2023 at 6:48 AM Sam James <s...@gentoo.org> wrote: > > > Eric Gallager via Gcc <gcc@gcc.gnu.org> writes: > > > 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. > > I think this might be more frustrating than not, althuogh I appreciate > the intent. > > Neal Gompa wasn't keen on the idea at > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=od5dh+h9aqzge_4ghzgx_ow4ryjvpw...@mail.gmail.com/ > because it'd feel like essentially "repeated punches". > > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 > having > implicit-function-declaration,implicit-int (these are so closely related > that it's not worth dividing the two up) and then say, GCC 15 having > int-conversion and maybe > incompatible-pointer-types. But spreading it out too much is likely > counterproductive.
Right, we've been going through a similar effort with C++ over the past decade. GCC incrementally becoming more strict on C++ has been an incredibly painful experience, and it eats away a ton of time that I would have spent dealing with other problems. Having one big event where the majority of changes to make the C compiler strict happen will honestly make it less painful, even if it doesn't seem like it at the moment. This is because with as much C++ stuff we have in Linux distributions, we have so much more C stuff. -- 真実はいつも一つ！/ Always, there's only one truth!
