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.

thanks,
sam