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.
