On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
From: Arsen Arsenović <ar...@aarsen.me>
Cc: Eli Zaretskii <e...@gnu.org>, Jakub Jelinek <ja...@redhat.com>,
jwakely....@gmail.com, gcc@gcc.gnu.org
Date: Tue, 09 May 2023 22:21:03 +0200
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.
Both the GNU Toolchain and the GNU Toolchain users will benefit from a
stricter toolchain.
People can and have stopped using the GNU Toolchain due to lackluster
and non-strict defaults. This is certainly not positive for the brand,
and I doubt it buys it much good will.
It is not GCC's business to force developers of packages to get their
act together. It is the business of those package developers
themselves. GCC should give those developers effective and convenient
means of detecting any unsafe and dubious code and of correcting it as
they see fit. Which GCC already does by emitting warnings. GCC
should only error out if it is completely unable to produce valid
code, which is not the case here, since it has been producing valid
code for ages.
It is a disservice to GCC users if a program that compiled yesterday
and worked perfectly well suddenly cannot be built because GCC was
upgraded, perhaps due to completely unrelated reasons. It would be a
grave mistake on the part of GCC to decide that part of its mission is
to teach package developers how to write their code and when and how
to modify it.
That argument doesn't really wash. We already upgrade the 'default'
language version (-std=...) from time to time and that can impact
existing programs (eg we changed from gnu-inline to std-inline model).
If this really isn't legal C, then my suggestion would be to tie this to
a setting of -std, so -std=c2<something> would default to being more
aggressive in enforcing this (via changing the warning to -werror=) and
then -std=gnu2<something-later> might follow a bit behind that.
Furthermore, we can trail this aggressively in release notes so that
nobody can really claim to be surprised.
At some point that std setting will become the default and the overall
goal is achieved.
R.
