> Date: Thu, 11 May 2023 18:43:32 -0400 > Cc: luang...@yahoo.com, gcc@gcc.gnu.org > From: Eli Schwartz <eschwart...@gmail.com> > > On 5/11/23 2:24 AM, Eli Zaretskii wrote: > > > Back to the subject: the guarantees I would personally like to have is > > that the current GCC development team sees backward compatibility as > > an important goal, and will try not to break old programs without very > > good technical reasons. At least in Emacs development, that is the > > consideration that is very high on our priority list when making > > development decisions. It would be nice if GCC (and any other GNU > > project, for that matter) would do the same, because being able to > > upgrade important tools and packages without fear is something users > > value very much. Take it from someone who uses GCC on various > > platforms since version 1.40. > > This discussion thread is about having very good technical reasons -- as > explained multiple times, including instances where you agreed that the > technical reasons were good.
They are not technical, no. Leaving the current behavior does not technically hamper GCC and its users in any way -- GCC can still compile the same programs, including those with modern std= values, as it did before, and no false warnings or errors are caused when compiling programs written in valid standard C. The reasons are basically PR: better reputation for GCC etc. Maybe even fashion: Clang does that, so how come we don't? > Furthermore, even despite those technical reasons, GCC is *still* > committed to not breaking those old programs anyway. GCC merely wants to > make those old programs have to be compiled in an "old-programs" mode. > > Can you explain to me how you think this goal conflicts with your goal? I already did, in previous messages, where I described what we all are familiar with: the plight of a maintainer of a large software system whose build suddenly breaks, and the difficulty in understanding which part of the system's upgrade caused that. I'd rather not repeat that: there are already too many repetitions here that make the discussion harder to follow.