> From: Jonathan Wakely <jwakely....@gmail.com> > Date: Fri, 12 May 2023 08:28:00 +0100 > Cc: Eli Schwartz <eschwart...@gmail.com>, Po Lu <luang...@yahoo.com>, > "gcc@gcc.gnu.org" <gcc@gcc.gnu.org> > > 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.
I'm sad to hear that you consider this laughable. I hope the development team as a whole and the steering committee will consider that more seriously. > 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. GCC already helps those people who want to be helped. This was pointed out several times. > 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. That's just a bunch of slogans. Decisions about backward-incompatible changes should do better than heed slogans. > > 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. Considered and dismissed, it seems, at least judging by your responses. As for when it can be violated, I already explained my opinions. TL;DR: there are valid cases, but not in this case. > 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. These decisions should not be based on majority votes. Breaking even one person's code is much worse than helping many others realize more clearly their code needs to be fixed. > Do you have anything new to add other than repeating the same arguments? > We've heard them now, > thanks. Oh, please drop the attitude. You are not making your arguments more convincing by being hostile and ad-hominem. We are supposed to have the same goals.
