My perception is that more and better warnings, and common use of -Wall, came into vogue around the time of GCC 4, in the mid 2000s. It would have been pretty abrupt to immediately enforce C99 in 1999-2000.
Yet in 2022 this change from warn by default to error by default was consequential enough for Fedora:
>> So what is the current status? How many packages are going to be affected by this change? How are we going to track the progress?
> I see an unaudited rebuild failure rate of about 10% for rebuilds of source packages that produce arch-full binary packages. This number does not include packages which fail to build in rawhide without the compiler change. It includes packages which configure checks for something that we really do not support (like setproctitle or strlcpy). After the first pass completes, I'll have to do a second pass with the expected-to-be-undeclared functions gathered from the first pass filtered out. That should give us better numbers.
My impression is that a lot of the fallout was related to checks in configure scripts and equivalent. That kind of code was traditionally written a lot more sloppily and was much less likely to have the "standard" set of warnings or the make-warnings-into-errors flag enabled. So, yes, quite a lot of packages failed to build, but the offending code was typically not code that was run when somebody was actually using the program and not code where bugs were consequential. And of course Fedora's a big collection of software with a pretty long tail -- 10% of packages likely works out to a lot less than 10% of user-executing-a-program hours.
I would guess that the main cause of failures is autoconf, which has a habit of relying on extremely dubious C code to check for feature availability. On top of that, the compiler runs are done in a way to guarantee that no one will see any warnings, even errors can tend to be silently ignored (!), and a particular version is often baked into a source package, so upgrading autoconf to a more sane version tends to take eons.
