On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > From: Arsen Arsenović <ar...@aarsen.me>
> > Cc: luang...@yahoo.com, jwakely....@gmail.com, gcc@gcc.gnu.org
> > Date: Thu, 11 May 2023 21:25:53 +0200
> >
> > >> This seems like a good route to me - it facilitates both veterans
> > >> maintaining code and beginners just learning how to write C.
> > >
> > > No, it prefers beginners (which already have the warnings, unless they
> > > deliberately turn them off) to veterans who know what they are doing,
> > > and can live with those warnings.
> >
> > Indeed. I said facilitates, not treats equally. I think the veterans
> > here won't lose much by having to pass -fpermissive, and I think that's
> > a worthwhile sacrifice to make, to nurture the new without pressuring
> > the old very much.
>
> Let's keep in mind that veterans are much more likely to have to deal
> with very large programs than newbies, and so dealing with breakage
> for them is much harder than doing that in a toy program. Thus, the
> proposal does "pressure the old very much".
Pressure for something they should have done decades ago if the code was
really maintained.
Anyway, I don't understand why these 3 (implicit fn declarations,
implicit ints and int-conversions) are so different from anything that
one needs to change in codebases every year as documented in
gcc.gnu.org/gcc-NN/porting_to.html . It is true that for C++ there are
more such changes than for C, but say GCC 12 no longer accepts
computed gotos with non-pointer types, GCC 10 changed default from
-fcommon to -fno-common for C which also affects dusty codebases
significantly, GCC 9 changed the lifetime of block scope compound literals
(again, affected various old codebases), GCC 5 broke bad user expectations
regarding preprocessor behavior by adding extra line markers to represent
whether certain tokens come from system headers or not, etc.
And of course compiler optimizations added every year can turn previously
"working" code with undefined behaviors in it into code not working as user
expected. E.g. compared to the above 3 that are easily fixed, it is obvious
what the problem is, tracking undefined behavior in code even when one
has sanitizers etc. is much more time consuming.
Can we stop this thread. I'm afraid everything has been said multiple
times, it is up to the GCC Steering Committee to decide this if there is
disagreement on it among GCC developers, but my current understanding is
that that is not the case here and that the active GCC developers agree on
it.
Jakub
