Re: More C type errors by default for GCC 14

[David Edelsohn <dje.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]

On Tue, May 9, 2023 at 4:40 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

>
>
> On Tue, 9 May 2023, 21:13 David Edelsohn, <dje.gcc@gmail.com> wrote:
>
>> 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 <jakub@redhat.com>
>>> > Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, arsen@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.gcc@gmail.com>
>>> > > > Date: Tue, 9 May 2023 18:15:59 +0100
>>> > > > Cc: Arsen Arsenović <arsen@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.
>>
>
> So let's do it. Let's write a statement saying that the GCC developers
> consider software security to be of increasing importance, and that we
> consider it irresponsible to default to accepting invalid constructs in the
> name of backwards compatibility. State that we will make some changes which
> were a break from GCC's traditional stance, for the good of the ecosystem.
>
> Given recent pushes to discourage or outright ban the use of memory-safe
> languages in some domains, I think it would be good to make a strong
> statement about taking the topic seriously. And not just make a statement,
> but take action too.
>
> If we don't do this, I believe it will harm GCC in the long run. The vocal
> minority who want to preserve the C they're used to, like some kind of
> historical reenactment society, would get their wish: it would become a
> historical dead end and go nowhere.
>

I recently was discussing with a colleague that the C Language has been
rather conservative in its changes relative to other programming languages
with long histories.  It probably has been somewhat constrained by the
existing Unix/Linux ecosystem and somewhat by C++ providing a C-adjacent
environment in which to experiment with more radical changes, not to
mention Objective-C, Objective-C++.

Yes, memory safe languages have become the topic de rigueur.  That
constituency probably only will be satisfied by gccrs, but we still should
try to improve GCC.  The danger is developers who stop upgrading GCC and
who do not receive other bug fixes.

We can make software security one of the driving principles of GCC and
state that explicitly.  GCC needs a point of view.

Thanks, David