c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	c-std-porting@lists.linux.dev, gcc@gcc.gnu.org
Subject: Re: More C type errors by default for GCC 14
Date: Tue, 09 May 2023 16:07:50 +0100	[thread overview]
Message-ID: <877ctho7x6.fsf@gentoo.org> (raw)
In-Reply-To: <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>

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

David Edelsohn via Gcc <gcc@gcc.gnu.org> writes:

> On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> wrote:
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>> A few of you might remember that I've been looking into turning some
>> type errors from warnings into errors by default.  Mainly I've been
>> looking at implicit function declarations because in too many cases, the
>> synthesized declaration does not match the prototype used at function
>> definition and can cause subtle ABI issues.
>> To recap, the main challenge is that GCC has to serve disparate groups
>> of users: some use GCC for writing programs themselves, but others just
>> need GCC to build sources that they have obtained from somewhere.  The
>> first group benefits from more type errors because they catch errors
>> earlier during development (experience shows that compiler warnings are
>> easy to miss in a long build log).  The second group might find these
>> errors challenging because the sources they have no longer build.
> Hi, Florian
> Thanks for working on this and proposing this.
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

Florian did note this already - ABI. Implicit function declarations are
pretty horrible in a number of cases:
- they prevent fortification (_FORTIFY_SOURCE)
- they prevent time64 and LFS migrations from working correctly
- they break with different ABIs (see e.g. Apple's arm64 ABI)
- they can cause runtime crashes when combined wtih bfd's default of
not warning on underlinking

int-conversion generally indicates severe runtime problems as well. Many
of the cases I've seen on musl absolutely do not work at runtime and
weren't caught by any other warnings (often because of padding mismatches).

> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.

That's why Fedora and Gentoo have been aggressively working on this
before even proposing it. We are being proactive in making sure that
common things are fixed.

> Clang has been making some aggressive changes in warnings,
> but its constituency expects that.  Developers who want that experience
> already will use Clang, so why annoy developers who prefer the GCC
> experience and behavior?  The new warnings and errors help some developers
> and improve software security, but also drive some developers away, or at
> least cause them to reass their choice of toolchain.

I don't know if it's that aggressive to drop something which was
removed in C99 because of how dangerous it is.

Also, keep in mind, Florian went around and asked many of the first
group (the foundational folks) who didn't object.

Not that this is a strong argument, and I don't like making it, but
if Clang is doing it and GCC does too, it's not like they can reassess
their choices anyway.

> Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
> GCC to provide an experience more like Clang for those who desire that.
> GCC isn't Clang and I fear that GCC is going down a path that annoys and
> frustrates both user groups -- it's not sufficiently aggressive for those
> who prefer Clang and it's too aggressive for those who wish backward
> compatibility.

Sounds similar (although a bit different) to the
https://gcc.gnu.org/wiki/boringcc idea.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

  parent reply	other threads:[~2023-05-09 15:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 12:15 More C type errors by default for GCC 14 Florian Weimer
2023-05-09 15:16 ` Richard Biener
2023-05-09 16:05   ` Jakub Jelinek
2023-05-09 16:11     ` Sam James
2023-05-09 16:59   ` Florian Weimer
2023-05-09 17:07     ` Sam James
2023-05-09 17:35       ` Florian Weimer
     [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
2023-05-09 15:07   ` Sam James [this message]
2023-05-09 15:14   ` Jonathan Wakely
     [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
     [not found]       ` <87r0rp5uf8.fsf@aarsen.me>
     [not found]         ` <83ttwla1ep.fsf@gnu.org>
     [not found]           ` <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
     [not found]             ` <83lehx9vix.fsf@gnu.org>
     [not found]               ` <ZFqZ25xKm4w4IkqF@tucnak>
     [not found]                 ` <83fs859unu.fsf@gnu.org>
     [not found]                   ` <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
     [not found]                     ` <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
     [not found]                       ` <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
     [not found]                         ` <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
     [not found]                           ` <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
     [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
2023-05-10 10:45                               ` Sam James
2023-05-10 10:56                                 ` Neal Gompa
2023-05-10 12:06                                   ` Eli Zaretskii
2023-05-10 12:10                                     ` Neal Gompa
2023-05-10 12:41                                       ` Eli Zaretskii
2023-05-09 18:22   ` Florian Weimer
2023-05-11 21:32     ` Segher Boessenkool
2023-05-12  9:33 ` Martin Jambor
2023-05-12 12:30   ` Jakub Jelinek
2023-05-15 12:46     ` Michael Matz
2023-05-15 13:14     ` Richard Earnshaw (lists)
     [not found] <CAGWvnynMpa83AduLhRhf1PxkVujngDmmwE7Z4vk1z6+UqqAuKA@mail.gmail.com>
     [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44   ` Florian Weimer
2023-05-09 16:58     ` Ian Lance Taylor
2023-05-09 17:08     ` Jason Merrill
2023-05-09 17:16       ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ctho7x6.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=dje.gcc@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).