On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:
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 current behavior hampers GCC's users in very significant ways: it encourages people who are new to the language to write completely broken code in ways that should have been at least slightly harder to accomplish since a quarter of a century ago.
Arguing that GCC should compile any "valid standard C" seems like an obviously flawed premise to me given that unless you're going the strictly conforming route, a "program" such as:
]iN$<\J3"`q
Tf;9ge0k\hm[
!Zsr>MtiV B@
~x?M\A):.s0^W
2$((g]'Vx:jZ
D'?n/X_li|;E
aLA%WQmzNq-(QG'
r"rSV3|]k_BU?R
p:hPWg_(]Y(
And,3xD{iR5B
may be considered by any implementation as a valid standard C program,
since it does not contain an #error directive.
Such examples may seem like hyperbole to you, but to a beginner, the constructs that you wish to leave usable in GCC unaltered may well be just about as confusing as you might find any interpretation of the valid standard C program presented above to be.
You may not be aware of this, but the current behavior leads to endless instances of beginners accidentally using utterly broken constructs and then coming to C forums/channels/etc. asking for help, only for people like me to discover that such code is still compiled by GCC now without anymore than a warning being given to the user (which they extremely commonly ignore). Having been on such forums for years, I'd estimate that this actually represents a genuinely significant proportion of the problems I help diagnose - about 10% or so (though I have of course not made a detailed study of every problem I've ever helped solve, but I'm relatively confident 10% is not too far from the real proportion). To be honest, it's such a common problem that I'm genuinely surprised it hasn't spawned off jokes in the same way things like T_PAAMAYIM_NEKUDOTAYIM in PHP have (I guess "implicit function declaration" has less of a ring to it than T_PAAMAYIM_NEKUDOTAYIM)
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.
