Re: More C type errors by default for GCC 14

[Jonathan Wakely <jwakely.gcc@gmail.com>]

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

On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc, <gcc@gcc.gnu.org> wrote:

> > Date: Thu, 11 May 2023 23:07:55 -0400
> > Cc: gcc@gcc.gnu.org
> > From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> >
> > > Being sceptical about the future is perfectly reasonable.
> >
> > My opinion on this is (still) that if your argument is that you don't
> > want -fpermissive or -std=c89 to be removed, you are more than welcome
> > to be skeptical about that (either one or both), but I don't see why
> > that is on topic for the question of whether things should be moved to
> > flags such as those while they do exist.
>
> It is on topic because there doesn't seem to be anything in the
> arguments brought up for this current proposal that couldn't be
> brought up in favor of removing -fpermissive.  There are no guiding
> principles being uttered which allow the current proposal, but will
> disallow the removal of -fpermissive.



"Let's change a default and add an option to get the old default" is really
not the disaster you're making it out to be. You're becoming a laughing
stock at this point.


The same "let's be more popular
> and forthcoming to newbies, and more like Clang" PR-style stuff can
> justify both.
>


It's not about popularity. If that's your takeaway then you're not paying
attention, whatever you claim about reading everything in the thread. It's
about helping people write correct code, first time, without some of the
avoidable traps that C presents.

The C ecosystem has a shockingly bad reputation when it comes to security
and "just don't write bugs" is naive and ineffective. Maybe you're good
enough for that to work, but then you should also be able to cope with a
change in defaults.

It's time for some defaults to change so that modern C is preferred, and
"implicit everything, hope the programmer got it right" requires explicit
action, *but it's still possible to do* for the 1970s nostalgia fans.

If you want to believe that's the start of a slippery slope, that's your
choice. The nostalgia club can always fork gcc if necessary, that's one of
the great things about free software.


> > We might as well assume that the GCC developers are honest and truthful
> > people, otherwise it is *definitely* a waste of time asking them about
> > this change in the first place.
>
> This is not about honesty.  No one is questioning the honesty of GCC
> developers.  What is being questioned are the overriding principles
> that should be applied when backward-incompatible changes are
> proposed.  Are there such principles in GCC development, and if there
> are, where are they documented?  Or are such discussions just some
> ad-hoc disputes, and the results are determined by which party is at
> that time more vocal?
>

GCC has always taken backwards compatibility seriously. That doesn't mean
it is the prime directive and can never be violated, but it's absolutely
always considered. In this case, changing the default seems appropriate to
many people, including those who actually maintain gcc and deal with the
consequences of the current defaults.

Do you have anything new to add other than repeating the same arguments?
We've heard them now, thanks.