On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc <gcc@gcc.gnu.org> wrote:
> > Date: Tue, 9 May 2023 21:07:07 +0200 > > From: Jakub Jelinek <ja...@redhat.com> > > Cc: Jonathan Wakely <jwakely....@gmail.com>, ar...@aarsen.me, > gcc@gcc.gnu.org > > > > On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote: > > > > From: Jonathan Wakely <jwakely....@gmail.com> > > > > Date: Tue, 9 May 2023 18:15:59 +0100 > > > > Cc: Arsen Arsenović <ar...@aarsen.me>, gcc@gcc.gnu.org > > > > > > > > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote: > > > > > > > > > > No one has yet explained why a warning about this is not enough, > and > > > > > why it must be made an error. Florian's initial post doesn't > explain > > > > > that, and none of the followups did, although questions about > whether > > > > > a warning is not already sufficient were asked. > > > > > > > > > > That's a simple question, and unless answered with valid arguments, > > > > > the proposal cannot make sense to me, at least. > > > > > > > > People ignore warnings. That's why the problems have gone unfixed for > > > > so many years, and will continue to go unfixed if invalid code keeps > > > > compiling. > > > > > > People who ignore warnings will use options that disable these new > > > errors, exactly as they disable warnings. So we will end up not > > > > Some subset of them will surely do that. But I think most people will > just > > fix the code when they see hard errors, rather than trying to work around > > them. > > The same logic should work for warnings. That's why we have warnings, > no? > This seems to be the core tension. If developers cared about these issues, they would enable appropriate warnings and -Werror. The code using these idioms is not safe and does create security vulnerabilities. And software security is increasingly important. The concern is using the good will of the GNU Toolchain brand as the tip of the spear or battering ram to motivate software packages to fix their problems. It's using GCC as leverage in a manner that is difficult for package maintainers to avoid. Maybe that's a necessary approach, but we should be clear about the reasoning. Again, I'm not objecting, but let's clarify why we are choosing this approach. Thanks, David