More C type errors by default for GCC 14

More C type errors by default for GCC 14

[Florian Weimer]

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.

To see how large the impact is on that second group, we've mostly
removed implicit function declarations and implicit ints from Fedora:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

Roughly 870 packages out of ~14,500 that have GCC present during the
build needed fixing (or flagging that they can't be built with the
additional errors), so 6%.  Most of the changes are mechanical in
nature, like adding additional headers to configure checks.  For about
~150 packages, automated patching could be used to rewrite problematic
built-in checks generated by long-obsolete autoconf versions.

Some of these changes prevent the compiler behavior for altering the
build results silently because the new errors changed the outcome of
autoconf checks.  (We had one of those in libstdc++, changing the ABI on
GNU/Linux because futex support oculd no longer be detected.)
Unfortunately, I did not record numbers about them, but think those were
quite rare; most autoconf problems were also accompanied with other
problems, or the incorrect results from autoconf led to build failures
later.  So it seems to me that the risk that the second group mentioned
above would silently get unexpected build results is fairly low.

Where possible, we tried to upstream patches, to simplify sharing across
distributions and to help those who compile upstream sources directly.
We also benefited from other distributions upstreaming changes along
similar lines (notably Gentoo for their Clang 16 project, but also from
Homebrew to a lesser extent).

An area we started exploring only recently for Fedora is implicit
conversions between integers and pointers (covered by -Wint-conversion).
These add another ~170 packages, but some of those are false positives
(due to our instrumented compiler approach) that do not change the build
outcome at all.  I'm still negotiating whether we have the capacity to
develop fixes for these packages proactively.

I brought up the matter with distributions, and the feedback was neutral
(not overly negative, as in “this would be the end of the world for
us”).

  <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
  <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
  <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>

(I tried to contact Arch, but my message didn't make it past the
moderators, it seems.)

All in all, the whole situation is not great, but it still seems
manageable to me.

Anyway, thanks for reading this far.

I would like to suggest to turn implicit-int,
implicit-function-declaration, and possibly int-conversion from warnings
into errors for GCC 14.  This would give upstream projects roughly
another year to make new releases with compatibility fixes that have
been contributed so far.  I do not think waiting longer, until GCC 15,
would make a meaningful difference because any upstream project that
does not release within the next 12 months is not likely to release in
the next 24 months, either.

Regarding mechanics of the necessary opt out facility, Clang used
-Werror=… by default, but that seems a bit hackish to me.  Presently, we
cannot use -std=gnu89 etc. to opt out because there are packages which
require both C89-only language features and C99-style inlining, which is
currently not a combination supported by GCC (but maybe that could be
changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
separate, and a flag approach that works for C and C++ without
introducing any new warnings would be most convenient.  So maybe we
could use -fpermissive for C as well.

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.

I have no data how big the compatibility impact of turning
incompatible-pointer-types into errors will be.  For now, int-conversion
has higher priority.  However, it looks like another change that could
benefit developers (the first group).

I do not plan to work specifically on C2X compatibility fixes for now
(to support bool-as-keyword, for example), but I could imagine a similar
project a few years from now, fewer than 25 hopefully, that would enable
GCC to make the switch to C2X by default.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Dave Blanchard]

How about this as a suitable compromise: 

Just introduce a new compiler option, maybe something like -Wjesus-christ-I-am-really-fucking-anal-and-definitely-want-EVERYTHING-TO-BE-AN-ERROR. That way all of the weirdos who want 90% of their system build to fail with ridiculously pedantic errors can have a way to make that happen for themselves (hooray!), while the rest of us who are simply trying to compile 1,000+ packages of other people's code don't have to write 10,000 patches to get the damn thing to build. OK? 

I'm already sick of the hell you've put us through so far in the past few GCC versions, like disabling fcommon by default, which was completely retarded and unnecessary. At some point I'm just going to quit "upgrading" GCC to keep my sanity, and keep from having to patch GCC to undo the brain damage. 

Dave


On Tue, 09 May 2023 14:15:40 +0200
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.
> 
> To see how large the impact is on that second group, we've mostly
> removed implicit function declarations and implicit ints from Fedora:
> 
>   <https://fedoraproject.org/wiki/Changes/PortingToModernC>
>   <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
> 
> Roughly 870 packages out of ~14,500 that have GCC present during the
> build needed fixing (or flagging that they can't be built with the
> additional errors), so 6%.  Most of the changes are mechanical in
> nature, like adding additional headers to configure checks.  For about
> ~150 packages, automated patching could be used to rewrite problematic
> built-in checks generated by long-obsolete autoconf versions.
> 
> Some of these changes prevent the compiler behavior for altering the
> build results silently because the new errors changed the outcome of
> autoconf checks.  (We had one of those in libstdc++, changing the ABI on
> GNU/Linux because futex support oculd no longer be detected.)
> Unfortunately, I did not record numbers about them, but think those were
> quite rare; most autoconf problems were also accompanied with other
> problems, or the incorrect results from autoconf led to build failures
> later.  So it seems to me that the risk that the second group mentioned
> above would silently get unexpected build results is fairly low.
> 
> Where possible, we tried to upstream patches, to simplify sharing across
> distributions and to help those who compile upstream sources directly.
> We also benefited from other distributions upstreaming changes along
> similar lines (notably Gentoo for their Clang 16 project, but also from
> Homebrew to a lesser extent).
> 
> An area we started exploring only recently for Fedora is implicit
> conversions between integers and pointers (covered by -Wint-conversion).
> These add another ~170 packages, but some of those are false positives
> (due to our instrumented compiler approach) that do not change the build
> outcome at all.  I'm still negotiating whether we have the capacity to
> develop fixes for these packages proactively.
> 
> I brought up the matter with distributions, and the feedback was neutral
> (not overly negative, as in “this would be the end of the world for
> us”).
> 
>   <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
>   <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
>   <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>
> 
> (I tried to contact Arch, but my message didn't make it past the
> moderators, it seems.)
> 
> All in all, the whole situation is not great, but it still seems
> manageable to me.
> 
> Anyway, thanks for reading this far.
> 
> I would like to suggest to turn implicit-int,
> implicit-function-declaration, and possibly int-conversion from warnings
> into errors for GCC 14.  This would give upstream projects roughly
> another year to make new releases with compatibility fixes that have
> been contributed so far.  I do not think waiting longer, until GCC 15,
> would make a meaningful difference because any upstream project that
> does not release within the next 12 months is not likely to release in
> the next 24 months, either.
> 
> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.
> 
> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
> 
> I have no data how big the compatibility impact of turning
> incompatible-pointer-types into errors will be.  For now, int-conversion
> has higher priority.  However, it looks like another change that could
> benefit developers (the first group).
> 
> I do not plan to work specifically on C2X compatibility fixes for now
> (to support bool-as-keyword, for example), but I could imagine a similar
> project a few years from now, fewer than 25 hopefully, that would enable
> GCC to make the switch to C2X by default.
> 
> Thanks,
> Florian
> 


-- 
Dave Blanchard <dave@killthe.net>

Re: More C type errors by default for GCC 14

[David Edelsohn]

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

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.

GCC needs to be proactive, not reactive, without annoying and frustrating
its user base.  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.

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.

Thoughts?

Thanks, David


>
> To see how large the impact is on that second group, we've mostly
> removed implicit function declarations and implicit ints from Fedora:
>
>   <https://fedoraproject.org/wiki/Changes/PortingToModernC>
>   <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
>
> Roughly 870 packages out of ~14,500 that have GCC present during the
> build needed fixing (or flagging that they can't be built with the
> additional errors), so 6%.  Most of the changes are mechanical in
> nature, like adding additional headers to configure checks.  For about
> ~150 packages, automated patching could be used to rewrite problematic
> built-in checks generated by long-obsolete autoconf versions.
>
> Some of these changes prevent the compiler behavior for altering the
> build results silently because the new errors changed the outcome of
> autoconf checks.  (We had one of those in libstdc++, changing the ABI on
> GNU/Linux because futex support oculd no longer be detected.)
> Unfortunately, I did not record numbers about them, but think those were
> quite rare; most autoconf problems were also accompanied with other
> problems, or the incorrect results from autoconf led to build failures
> later.  So it seems to me that the risk that the second group mentioned
> above would silently get unexpected build results is fairly low.
>
> Where possible, we tried to upstream patches, to simplify sharing across
> distributions and to help those who compile upstream sources directly.
> We also benefited from other distributions upstreaming changes along
> similar lines (notably Gentoo for their Clang 16 project, but also from
> Homebrew to a lesser extent).
>
> An area we started exploring only recently for Fedora is implicit
> conversions between integers and pointers (covered by -Wint-conversion).
> These add another ~170 packages, but some of those are false positives
> (due to our instrumented compiler approach) that do not change the build
> outcome at all.  I'm still negotiating whether we have the capacity to
> develop fixes for these packages proactively.
>
> I brought up the matter with distributions, and the feedback was neutral
> (not overly negative, as in “this would be the end of the world for
> us”).
>
>   <
> https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390
> >
>   <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
>   <
> https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J
> >
>
> (I tried to contact Arch, but my message didn't make it past the
> moderators, it seems.)
>
> All in all, the whole situation is not great, but it still seems
> manageable to me.
>
> Anyway, thanks for reading this far.
>
> I would like to suggest to turn implicit-int,
> implicit-function-declaration, and possibly int-conversion from warnings
> into errors for GCC 14.  This would give upstream projects roughly
> another year to make new releases with compatibility fixes that have
> been contributed so far.  I do not think waiting longer, until GCC 15,
> would make a meaningful difference because any upstream project that
> does not release within the next 12 months is not likely to release in
> the next 24 months, either.
>
> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.
>
> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
>
> I have no data how big the compatibility impact of turning
> incompatible-pointer-types into errors will be.  For now, int-conversion
> has higher priority.  However, it looks like another change that could
> benefit developers (the first group).
>
> I do not plan to work specifically on C2X compatibility fixes for now
> (to support bool-as-keyword, for example), but I could imagine a similar
> project a few years from now, fewer than 25 hopefully, that would enable
> GCC to make the switch to C2X by default.
>
> Thanks,
> Florian
>
>

Re: More C type errors by default for GCC 14

[Sam James]

[-- 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.

thanks,
sam

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

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
> 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.
>
> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.  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.
>
> 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.

This isn't "be like Clang", this is "diagnose things that have been
invalid C since 1999".

Accepting invalid code by default is a disservice to users. Those who
need to compile invalid C code can use an extra option to allow it,
the default should be to tell users their code is doing something bad.

Re: More C type errors by default for GCC 14

[Richard Biener]

> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
> 
> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.

I suppose the goal is to not need to rely on altering CFLAGS but change the default behavior with still being able to undo this using -Wno-error= or -Wno-?

I think instead of hard-coding a set of changes would it be possible to alter the default setting of diagnostic options during GCC configuration?  And maybe even note that when diagnosing?

Thanks,
Richard 

> 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.
> 
> To see how large the impact is on that second group, we've mostly
> removed implicit function declarations and implicit ints from Fedora:
> 
>  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
>  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
> 
> Roughly 870 packages out of ~14,500 that have GCC present during the
> build needed fixing (or flagging that they can't be built with the
> additional errors), so 6%.  Most of the changes are mechanical in
> nature, like adding additional headers to configure checks.  For about
> ~150 packages, automated patching could be used to rewrite problematic
> built-in checks generated by long-obsolete autoconf versions.
> 
> Some of these changes prevent the compiler behavior for altering the
> build results silently because the new errors changed the outcome of
> autoconf checks.  (We had one of those in libstdc++, changing the ABI on
> GNU/Linux because futex support oculd no longer be detected.)
> Unfortunately, I did not record numbers about them, but think those were
> quite rare; most autoconf problems were also accompanied with other
> problems, or the incorrect results from autoconf led to build failures
> later.  So it seems to me that the risk that the second group mentioned
> above would silently get unexpected build results is fairly low.
> 
> Where possible, we tried to upstream patches, to simplify sharing across
> distributions and to help those who compile upstream sources directly.
> We also benefited from other distributions upstreaming changes along
> similar lines (notably Gentoo for their Clang 16 project, but also from
> Homebrew to a lesser extent).
> 
> An area we started exploring only recently for Fedora is implicit
> conversions between integers and pointers (covered by -Wint-conversion).
> These add another ~170 packages, but some of those are false positives
> (due to our instrumented compiler approach) that do not change the build
> outcome at all.  I'm still negotiating whether we have the capacity to
> develop fixes for these packages proactively.
> 
> I brought up the matter with distributions, and the feedback was neutral
> (not overly negative, as in “this would be the end of the world for
> us”).
> 
>  <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
>  <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
>  <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>
> 
> (I tried to contact Arch, but my message didn't make it past the
> moderators, it seems.)
> 
> All in all, the whole situation is not great, but it still seems
> manageable to me.
> 
> Anyway, thanks for reading this far.
> 
> I would like to suggest to turn implicit-int,
> implicit-function-declaration, and possibly int-conversion from warnings
> into errors for GCC 14.  This would give upstream projects roughly
> another year to make new releases with compatibility fixes that have
> been contributed so far.  I do not think waiting longer, until GCC 15,
> would make a meaningful difference because any upstream project that
> does not release within the next 12 months is not likely to release in
> the next 24 months, either.
> 
> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.
> 
> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
> 
> I have no data how big the compatibility impact of turning
> incompatible-pointer-types into errors will be.  For now, int-conversion
> has higher priority.  However, it looks like another change that could
> benefit developers (the first group).
> 
> I do not plan to work specifically on C2X compatibility fixes for now
> (to support bool-as-keyword, for example), but I could imagine a similar
> project a few years from now, fewer than 25 hopefully, that would enable
> GCC to make the switch to C2X by default.
> 
> Thanks,
> Florian
> 

Re: More C type errors by default for GCC 14

[Dave Blanchard]

On Tue, 9 May 2023 16:14:28 +0100
Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:

> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".

And in the process, break half of my system, and make it even more of a pain in the ass to compile old software. With no real gain or benefit whatsoever. To hell with that bullshit.


> Accepting invalid code by default is a disservice to users. Those who
> need to compile invalid C code can use an extra option to allow it,
> the default should be to tell users their code is doing something bad.

The default ALREADY IS to tell users their code is doing something bad. It's called a "warning." Hello?


-- 
Dave Blanchard <dave@killthe.net>

Re: More C type errors by default for GCC 14

[David Edelsohn]

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

On Tue, May 9, 2023 at 11:14 AM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc <gcc@gcc.gnu.org>
> wrote:
> > 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.
> >
> > GCC needs to be proactive, not reactive, without annoying and frustrating
> > its user base.  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.
> >
> > 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.
>
> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".
>
> Accepting invalid code by default is a disservice to users. Those who
> need to compile invalid C code can use an extra option to allow it,
> the default should be to tell users their code is doing something bad.
>

I am not questioning the potential benefits.

I am suggesting that we should talk, as a community, about what we want GCC
to be so that we approach these transitions with some consensus on a
community strategy and not have members of the community feel that the
toolchain is embarking on changes with no strategy or a strategy that has
not been publicly expressed.

Thanks, David

Re: More C type errors by default for GCC 14

[Dave Blanchard]

On Tue, 09 May 2023 16:07:50 +0100
Sam James via Gcc <gcc@gcc.gnu.org> wrote:

> Florian did note this already - ABI. Implicit function declarations are
> pretty horrible in a number of cases:
> - they prevent fortification (_FORTIFY_SOURCE)

So what? Print a warning, for those who are writing new code or maintaining old code and actually care. Done.

> - they prevent time64 and LFS migrations from working correctly

So what? Print a warning, for those who are writing new code or maintaining old code and actually care. Done.

2038 is 15 years away. I'm trying to keep existing code working TODAY.

> - they break with different ABIs (see e.g. Apple's arm64 ABI)

I don't care about Apple or ARM64. I'm trying to keep old code working fine on x86.

> - they can cause runtime crashes when combined wtih bfd's default of
> not warning on underlinking

My system is perfectly stable, thanks. In fact it is much more stable and much snappier than the garbage released by the likes of Fedora, RedHat, etc. If runtime crashes and stability were a concern for those folks, they should start by dropping 'Linux Puttering' out of a helicopter.

> int-conversion generally indicates severe runtime problems as well. 

Not in my experience. My system works fine, despite approximately 10,000,000 warnings spit out by GCC during the build process.

> 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).

Well that's the risk you take by changing the C standard library. My system works fine on glibc. If any given package has a problem on musl, I will take that on a case by case basis. Wrecking my build process by introducing 10,000 new errors isn't part of the solution.

> 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.

Yeah, you're being proactive in ruining everything. Thanks. How's systemd and pulseaudio working out for you?

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

You're breaking old code unnecessarily by introducing an error, when the existing warning is perfectly fine.

If it was such a horrible, terrible, no-good thing that it must be removed immediately, then why wasn't this already changed decades ago? Hint: BECAUSE YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON.

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

No, he asked a few big shot million dollar well-funded distributions if they had any problems with increasing their workload and maybe hiring a few extra developers. Unsurprisingly that select group of insiders had no problem with it. Meanwhile there are thousands of other smaller users and organizations out there whose concerns are just as important.

> 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.

In fact that's exactly why GCC should continue just the way it is, so that people can have an actual alternative to the "bondage and discipline" approach, and continue keeping their old code working just fine when there are literally NO PROBLEMS with the status quo.


-- 
Dave Blanchard <dave@killthe.net>

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

Talking about dropping anybody out of a helicopter is not acceptable
on this mailing list. Stop it.

Learn to engage rationally or leave.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> 
> 
> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
> > 
> > TL;DR: This message is about turning implicit-int,
> > implicit-function-declaration, and possibly int-conversion into errors
> > for GCC 14.
> 
> I suppose the goal is to not need to rely on altering CFLAGS but change the default behavior with still being able to undo this using -Wno-error= or -Wno-?

Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
these errors that way?

	Jakub

Re: More C type errors by default for GCC 14

[Sam James]

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


Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>> 
>> 
>> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>> > 
>> > TL;DR: This message is about turning implicit-int,
>> > implicit-function-declaration, and possibly int-conversion into errors
>> > for GCC 14.
>> 
>> I suppose the goal is to not need to rely on altering CFLAGS but change the default behavior with still being able to undo this using -Wno-error= or -Wno-?
>
> Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
> these errors that way?

This is what we've been doing for hopeless projects and it's probably my
preference, but I'm fine with Florian's -fpermissive suggestion too.

(The point about inline semantics is important but you can handle that
with other flags anyway.)

best,
sam


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

Re: More C type errors by default for GCC 14

[David Edelsohn]

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

On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org>
wrote:

> On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> >
> >
> > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org
> >:
> > >
> > > TL;DR: This message is about turning implicit-int,
> > > implicit-function-declaration, and possibly int-conversion into errors
> > > for GCC 14.
> >
> > I suppose the goal is to not need to rely on altering CFLAGS but change
> the default behavior with still being able to undo this using -Wno-error=
> or -Wno-?
>
> Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
> these errors that way?
>

As Florian mentioned:

"Presently, we
cannot use -std=gnu89 etc. to opt out because there are packages which
require both C89-only language features and C99-style inlining, which is
currently not a combination supported by GCC (but maybe that could be
changed). "

David

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Dave Blanchard <dave@killthe.net> writes:

> On Tue, 09 May 2023 16:07:50 +0100
> Sam James via Gcc <gcc@gcc.gnu.org> wrote:
>
>> Florian did note this already - ABI. Implicit function declarations are
>> pretty horrible in a number of cases:
>> - they prevent fortification (_FORTIFY_SOURCE)
>
> So what? Print a warning, for those who are writing new code or maintaining old
> code and actually care. Done.
>
>> - they prevent time64 and LFS migrations from working correctly
>
> So what? Print a warning, for those who are writing new code or maintaining old
> code and actually care. Done.
>
> 2038 is 15 years away. I'm trying to keep existing code working TODAY.
>
>> - they break with different ABIs (see e.g. Apple's arm64 ABI)
>
> I don't care about Apple or ARM64. I'm trying to keep old code working fine on x86.

It doesn't work fine on x86 (or any other arch).  See the two points
above that you've baselessly dismissed.

>> - they can cause runtime crashes when combined wtih bfd's default of
>> not warning on underlinking
>
> My system is perfectly stable, thanks. In fact it is much more stable and much
> snappier than the garbage released by the likes of Fedora, RedHat, etc. If
> runtime crashes and stability were a concern for those folks, they should start
> by dropping 'Linux Puttering' out of a helicopter.

Employment of such language is unwanted, but sadly, I'm not surprised.

>> int-conversion generally indicates severe runtime problems as well. 
>
> Not in my experience. My system works fine, despite approximately 10,000,000
> warnings spit out by GCC during the build process.

You've actively and baselessly dismissed the general case (and are, and
I say this with a lot of confidence, missing subtle bugs on your
system).

>> 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).
>
> Well that's the risk you take by changing the C standard library. My system
> works fine on glibc. If any given package has a problem on musl, I will take
> that on a case by case basis. Wrecking my build process by introducing 10,000
> new errors isn't part of the solution.

The number of errors is far smaller than you estimate.  We've been
working through the queue for a while and have a decent idea of the
scope of the problem, and it is very manageable.

On top of that, the errors in question are largely trivial to fix,
unlike detecting the errors introduced by the current 'working' code.

>> 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.
>
> Yeah, you're being proactive in ruining everything. Thanks. How's systemd and
> pulseaudio working out for you?

They compile fine, and run without subtle bugs caused by constructs that
have been invalid for over 20 years.

>> I don't know if it's that aggressive to drop something which was
>> removed in C99 because of how dangerous it is.
>
> You're breaking old code unnecessarily by introducing an error, when the
> existing warning is perfectly fine.
>
> If it was such a horrible, terrible, no-good thing that it must be removed
> immediately, then why wasn't this already changed decades ago? Hint: BECAUSE
> YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON.

It doesn't work fine.  See the points that you've dismissed above.

The situation was also far simpler decades ago, and the actual trade-off
far greater (now invalid code is the exception).

>> Also, keep in mind, Florian went around and asked many of the first
>> group (the foundational folks) who didn't object.
>
> No, he asked a few big shot million dollar well-funded distributions if they
> had any problems with increasing their workload and maybe hiring a few extra
> developers. Unsurprisingly that select group of insiders had no problem with
> it. Meanwhile there are thousands of other smaller users and organizations out
> there whose concerns are just as important.

This seems irrelevant, and is not an accurate representation of who's
involved in the process.

>> 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.
>
> In fact that's exactly why GCC should continue just the way it is, so that
> people can have an actual alternative to the "bondage and discipline" approach,
> and continue keeping their old code working just fine when there are literally
> NO PROBLEMS with the status quo.

Current code is subtly broken.  It is a disservice to users to pretend
otherwise.

Have a lovely day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Dave Blanchard <dave@killthe.net> writes:

> On Tue, 9 May 2023 16:14:28 +0100
> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> And in the process, break half of my system, and make it even more of a pain in
> the ass to compile old software. With no real gain or benefit whatsoever. To
> hell with that bullshit.

Your system seems to be already broken.

You're actively dismissing the benefit.

>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The default ALREADY IS to tell users their code is doing something bad. It's
> called a "warning." Hello?

This construct is a blatant error and is easily fixable.  Not to mention
that it has been invalid, just the same as 'if {foo() == 3} ( bar{} );'
is.  We're currently not emitting a warning and accepting such code, so
I don't see why this blatantly invalid construct should be taken
differently, especially when it is an exception rather than a rule in
practice.

Have a great day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Richard Biener:

> > Am 09.05.2023 um 18:13 schrieb David Edelsohn <dje.gcc@gmail.com>:
> >
> > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> > > 
> > > 
> > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
> > > > 
> > > > TL;DR: This message is about turning implicit-int,
> > > > implicit-function-declaration, and possibly int-conversion into errors
> > > > for GCC 14.
> > > 
> > > I suppose the goal is to not need to rely on altering CFLAGS but
> > > change the default behavior with still being able to undo this
> > > using -Wno-error= or -Wno-?
> >
> > Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
> > these errors that way?
> >
> > As Florian mentioned:
> >
> > "Presently, we
> > cannot use -std=gnu89 etc. to opt out because there are packages which
> > require both C89-only language features and C99-style inlining, which is
> > currently not a combination supported by GCC (but maybe that could be
> > changed). "
>
> But surely it would reduce the number of packages to fix?  So I
> support both having only C99 and up reject no longer valid code _and_
> having -fpermissive be forgiving (demoting errors to warnings).

It makes sense to disable the new erros in C89 mode.  It's what I did in
the instrumented compiler.  It also gives you yet another way to disable
the errors, using CC=c89, which works for some packages that do not
honor CFLAGS and do not support whitespace in CC.

The part David quoted above is about this:

$ gcc -fno-gnu89-inline -std=gnu89 t.c
cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode

And some packages need -fno-gnu89-inline, but also rely on implicit ints
and implicit function declarations heavily.  With a purely C89-based
opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
compile these self-contradictory programs.  Hence the idea of
-fpermissive, in addition to the -std=gnu89 escape hatch.

But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
remaining reason for -fpermissive would be a flag that is accepted by
both gcc and g++, in case a package build system passes CFLAGS to g++ as
well, which sometimes happens.  And -fno-gnu89-inline is currently not
accepted by g++.  But in the Fedora package set, this (some C++ and a
C89 requirement) must be exceedingly rare because it's a subset of the
already tiny set of -fno-gnu89-inline -std=gnu89 packages.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 18:38:05 +0200
> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
> 
> You're actively dismissing the benefit.

Which benefit?

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.

Re: More C type errors by default for GCC 14

[Ian Lance Taylor]

On Tue, May 9, 2023 at 9:45 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>
> The part David quoted above is about this:
>
> $ gcc -fno-gnu89-inline -std=gnu89 t.c
> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>
> And some packages need -fno-gnu89-inline, but also rely on implicit ints
> and implicit function declarations heavily.  With a purely C89-based
> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
> compile these self-contradictory programs.  Hence the idea of
> -fpermissive, in addition to the -std=gnu89 escape hatch.
>
> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
> remaining reason for -fpermissive would be a flag that is accepted by
> both gcc and g++, in case a package build system passes CFLAGS to g++ as
> well, which sometimes happens.  And -fno-gnu89-inline is currently not
> accepted by g++.  But in the Fedora package set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=gnu89 packages.

I think I wrote that error, back in 2007, because I thought it was odd
to rely on the C99 semantics for inline functions when not using C99.
And to encourage people to move to C99.  But I wouldn't be surprised
if the compiler just works without the error.  It would just require
adding a few test cases similar to gcc.dg/inline-18.c through
inline-21.c (well, inline-21.c would have to be removed or rewritten).

Ian

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Richard Biener:

>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>> 
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>
> I suppose the goal is to not need to rely on altering CFLAGS but
> change the default behavior with still being able to undo this using
> -Wno-error= or -Wno-?

That's what Clang does (and the defaults chang along with -std=
settings). To me, -Werror by default for some warnings seems rather
hackish.  But that's just my personal preference, I do not have a strong
objection to doing it that way.

One downside with -Wno- is that some developers jump on this rather
quickly instead of fixing the real problem.  So far, I've seen this in
both Chromium and the kernel, in fringe areas admittedly, but still.
The advantage is that there is a familiar workaround to get things
compiling quickly again, of course.

> I think instead of hard-coding a set of changes would it be possible
> to alter the default setting of diagnostic options during GCC
> configuration?  And maybe even note that when diagnosing?

I'd be worried about our package maintainers if we do something like
that.  We'd like them to report build failures upstream, and if it's
just one or two distributions doing that and not GCC upstream, well, I
guess we just got a preview of how some upstreams are going to react.
Package maintainers tend to be volunteer or junior engineering roles, I
think, so this doesn't seem fair to me.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Sam James]

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


Eli Zaretskii via Gcc <gcc@gcc.gnu.org> writes:

>> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
>> 
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> 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.

My email covers this:
https://gcc.gnu.org/pipermail/gcc/2023-May/241269.html.

I'd also note that some of the issues I've seen were already flagged
in people's CI but they didn't notice because it was just a warning.

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

Re: More C type errors by default for GCC 14

[Sam James]

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


Florian Weimer <fweimer@redhat.com> writes:

> * Richard Biener:
>
>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>>> 
>>> TL;DR: This message is about turning implicit-int,
>>> implicit-function-declaration, and possibly int-conversion into errors
>>> for GCC 14.
>>
>> I suppose the goal is to not need to rely on altering CFLAGS but
>> change the default behavior with still being able to undo this using
>> -Wno-error= or -Wno-?
>
> That's what Clang does (and the defaults chang along with -std=
> settings). To me, -Werror by default for some warnings seems rather
> hackish.  But that's just my personal preference, I do not have a strong
> objection to doing it that way.

Not that we have to follow Clang, but deviating by adding -fpermissive
(which is a GCC-only flag) for C may not be desirable, and following
Clang would let people use the same method for silencing known-bad
codebases for now.

>
> One downside with -Wno- is that some developers jump on this rather
> quickly instead of fixing the real problem.  So far, I've seen this in
> both Chromium and the kernel, in fringe areas admittedly, but still.
> The advantage is that there is a familiar workaround to get things
> compiling quickly again, of course.
>

I've not seen very much of this so far, FWIW. Only for the more annoying
C23 warnings which have well-documented problems (and unrelated to this,
so I won't go on about it anymore).

But -fpermissive does have a nice property in that it's immediately
obvious you're doing something *terrible* if you use it.

>> I think instead of hard-coding a set of changes would it be possible
>> to alter the default setting of diagnostic options during GCC
>> configuration?  And maybe even note that when diagnosing?
>
> I'd be worried about our package maintainers if we do something like
> that.  We'd like them to report build failures upstream, and if it's
> just one or two distributions doing that and not GCC upstream, well, I
> guess we just got a preview of how some upstreams are going to react.
> Package maintainers tend to be volunteer or junior engineering roles, I
> think, so this doesn't seem fair to me.

Yeah, this is one of those things where we need it happening in CI for
people and at the point of development.

(Such an option might be nice in general, but not for this if its
default didn't include these warnings or if distributions were likely
to override it to something weaker.)

thanks,
sam


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

Re: More C type errors by default for GCC 14

[Jason Merrill]

On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>
> * Richard Biener:
>
> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn <dje.gcc@gmail.com>:
> > >
> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
> > >
> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> > > >
> > > >
> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
> > > > >
> > > > > TL;DR: This message is about turning implicit-int,
> > > > > implicit-function-declaration, and possibly int-conversion into errors
> > > > > for GCC 14.
> > > >
> > > > I suppose the goal is to not need to rely on altering CFLAGS but
> > > > change the default behavior with still being able to undo this
> > > > using -Wno-error= or -Wno-?
> > >
> > > Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
> > > these errors that way?
> > >
> > > As Florian mentioned:
> > >
> > > "Presently, we
> > > cannot use -std=gnu89 etc. to opt out because there are packages which
> > > require both C89-only language features and C99-style inlining, which is
> > > currently not a combination supported by GCC (but maybe that could be
> > > changed). "
> >
> > But surely it would reduce the number of packages to fix?  So I
> > support both having only C99 and up reject no longer valid code _and_
> > having -fpermissive be forgiving (demoting errors to warnings).
>
> It makes sense to disable the new erros in C89 mode.  It's what I did in
> the instrumented compiler.  It also gives you yet another way to disable
> the errors, using CC=c89, which works for some packages that do not
> honor CFLAGS and do not support whitespace in CC.
>
> The part David quoted above is about this:
>
> $ gcc -fno-gnu89-inline -std=gnu89 t.c
> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>
> And some packages need -fno-gnu89-inline, but also rely on implicit ints
> and implicit function declarations heavily.  With a purely C89-based
> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
> compile these self-contradictory programs.  Hence the idea of
> -fpermissive, in addition to the -std=gnu89 escape hatch.
>
> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
> remaining reason for -fpermissive would be a flag that is accepted by
> both gcc and g++, in case a package build system passes CFLAGS to g++ as
> well, which sometimes happens.  And -fno-gnu89-inline is currently not
> accepted by g++.  But in the Fedora package set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=gnu89 packages.

Another reason for -fpermissive is ease of use.  So if someone just
wants to get an older package to build, they can add -fpermissive
without having to figure out more detailed flags.

Alternatively, if we go the default -Werror=various route, adding
-Wno-error without any =foo to override everything might also be
fairly convenient.

In any case, I think we want an easy answer for the second group.


Jason

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
>
> > Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
> > Date: Tue, 09 May 2023 18:38:05 +0200
> > From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
> >
> > You're actively dismissing the benefit.
>
> Which benefit?
>
> 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.

Re: More C type errors by default for GCC 14

[Sam James]

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


Jason Merrill <jason@redhat.com> writes:

> On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> * Richard Biener:
>>
>> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn <dje.gcc@gmail.com>:
>> > >
>> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>> > >
>> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>> > > >
>> > > >
>> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>> > > > >
>> > > > > TL;DR: This message is about turning implicit-int,
>> > > > > implicit-function-declaration, and possibly int-conversion into errors
>> > > > > for GCC 14.
>> > > >
>> > > > I suppose the goal is to not need to rely on altering CFLAGS but
>> > > > change the default behavior with still being able to undo this
>> > > > using -Wno-error= or -Wno-?
>> > >
>> > > Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
>> > > these errors that way?
>> > >
>> > > As Florian mentioned:
>> > >
>> > > "Presently, we
>> > > cannot use -std=gnu89 etc. to opt out because there are packages which
>> > > require both C89-only language features and C99-style inlining, which is
>> > > currently not a combination supported by GCC (but maybe that could be
>> > > changed). "
>> >
>> > But surely it would reduce the number of packages to fix?  So I
>> > support both having only C99 and up reject no longer valid code _and_
>> > having -fpermissive be forgiving (demoting errors to warnings).
>>
>> It makes sense to disable the new erros in C89 mode.  It's what I did in
>> the instrumented compiler.  It also gives you yet another way to disable
>> the errors, using CC=c89, which works for some packages that do not
>> honor CFLAGS and do not support whitespace in CC.
>>
>> The part David quoted above is about this:
>>
>> $ gcc -fno-gnu89-inline -std=gnu89 t.c
>> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>>
>> And some packages need -fno-gnu89-inline, but also rely on implicit ints
>> and implicit function declarations heavily.  With a purely C89-based
>> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
>> compile these self-contradictory programs.  Hence the idea of
>> -fpermissive, in addition to the -std=gnu89 escape hatch.
>>
>> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
>> remaining reason for -fpermissive would be a flag that is accepted by
>> both gcc and g++, in case a package build system passes CFLAGS to g++ as
>> well, which sometimes happens.  And -fno-gnu89-inline is currently not
>> accepted by g++.  But in the Fedora package set, this (some C++ and a
>> C89 requirement) must be exceedingly rare because it's a subset of the
>> already tiny set of -fno-gnu89-inline -std=gnu89 packages.
>
> Another reason for -fpermissive is ease of use.  So if someone just
> wants to get an older package to build, they can add -fpermissive
> without having to figure out more detailed flags.
>
> Alternatively, if we go the default -Werror=various route, adding
> -Wno-error without any =foo to override everything might also be
> fairly convenient.

In addition to this, this made me realise something similar to what
Florian was saying wrt whitespace. Passing -Wno-error=... doesn't
always work with some poorly-written build scripts because they split
on '=' (this happens with some CMake when poorly written).

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

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> * Richard Biener:
>>
>>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>>>> 
>>>> TL;DR: This message is about turning implicit-int,
>>>> implicit-function-declaration, and possibly int-conversion into errors
>>>> for GCC 14.
>>>
>>> I suppose the goal is to not need to rely on altering CFLAGS but
>>> change the default behavior with still being able to undo this using
>>> -Wno-error= or -Wno-?
>>
>> That's what Clang does (and the defaults chang along with -std=
>> settings). To me, -Werror by default for some warnings seems rather
>> hackish.  But that's just my personal preference, I do not have a strong
>> objection to doing it that way.
>
> Not that we have to follow Clang, but deviating by adding -fpermissive
> (which is a GCC-only flag) for C may not be desirable, and following
> Clang would let people use the same method for silencing known-bad
> codebases for now.

I think Clang already accepts -fpermissive, so it's not *too* bad?
(Presumably it just ignores it.)

>> One downside with -Wno- is that some developers jump on this rather
>> quickly instead of fixing the real problem.  So far, I've seen this in
>> both Chromium and the kernel, in fringe areas admittedly, but still.
>> The advantage is that there is a familiar workaround to get things
>> compiling quickly again, of course.
>
> I've not seen very much of this so far, FWIW. Only for the more annoying
> C23 warnings which have well-documented problems (and unrelated to this,
> so I won't go on about it anymore).

I think this could be a side effect of our different testing strategies.
The kernel -Wno-implicit-function-declaration change looks like it was
specifically added to build with Clang 15/16.

> But -fpermissive does have a nice property in that it's immediately
> obvious you're doing something *terrible* if you use it.

Right.

> In addition to this, this made me realise something similar to what
> Florian was saying wrt whitespace. Passing -Wno-error=... doesn't
> always work with some poorly-written build scripts because they split
> on '=' (this happens with some CMake when poorly written).

Hmm, maybe I've seen this as well but attributed it to whitespace.
The -std=gnu89 approach would run into problems with this, too.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer]

* David Edelsohn:

> 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.

I tried to explain that in my introductory comments, but perhaps that
was a bit too abstract.

Here are some examples of the stuff I personally deal with in this space
on a semi-regular basis.

* alleged code generation bugs because the upper 32 bits of a pointer
  are set to zero or 0xffffffff, resulting in crashes.  This can happen
  if GCC synthesizes an implicit int declaration for a pointer-returning
  function.

* Alleged code generation bugs because a function returning bool does
  not set the entire register, as expected the caller.  This can happen
  if GCC makes up a function declaration returning int for a function
  that actually returns bool on x86-64.

* Making source-only API transitions away from a particular function is
  surprisingly hard if you still want to provide binary compatibility,
  and not put ugliness like

    #define function_api_v1(arg0, arg1, arg2) \
      DO NOT CALL THIS, USE function_api_v2 instead

  into installed header files (or rely on GCC extensions such as the
  poison pragma).

* Incomplete ports of C extensions to newer Python and Ruby versions
  which still compile and link, but fail at some point during run time
  because they try to call functions that do not exist.  (BIND_NOW
  mitigates that to some extend, but that's mostly a downstream thing.)

These are just a subset of the issues that are escalated to me, and I
don't even work on the compiler for real.  I don't know how much of that
ends up with the real compiler developers, or in how many cases
programmers eventually debug the issue on their own, finally spot the
warning in the build log, and make the connection.

Nowadays I ask for full build logs before I look at anything else, and
given the way we build our applications, we usually have that, so that
is a convenient shortcut.  (For others, it will be buried in some IDE,
and all you can get from them are screenshots.)  But if application
developers poked at the problem with GDB to the point that they can
share disassembly they think that shows a compiler bug, they must have
spent quite some time on it.  If GCC had different defaults, they
wouldn't have to do that, increasing their productivity.

I hope this makes things clearer.  I do think the current GCC defaults
are needlessly frustrating, which is why I spent so much time on proving
(from my perspective) that it should be feasible to change them.

> GCC needs to be proactive, not reactive, without annoying and
> frustrating its user base.  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?

I really would like to keep GCC as the system compiler, but avoid the
hidden costs of the current GCC defaults.

We can get fairly close by injecting appropriate -Werror= options during
the distribution build.  On the other hand, we are already up to about
fifteen recommended compiler flags.  We are looking at adding between
two and four additional -Werror= flags for this.  The optics aren't
great.  In our case, ISVs who do not do RPM builds would have to
replicate and maintain this flag list in their own build environments
because they wouldn't benefit from the distribution default flags.  I'm
worried all this looks rather unprofessional.

> 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.

That goes in the other direction as well, I think.  Developers are
pressured to use languages which are generally perceived to offer more
type safety.  Here we have a few cases where we could increase the type
safety of C, without having to switch to a completely different
language.

I don't think C is as static as used to be, by the way.  C2X (and glibc
before that, especially with _GNU_SOURCE) is adding lots of widely-used
identifiers to existing headers, so that will cause some breakage, too.
The C2X changes seem to conflict with keeping GCC as the 90s C compiler
(at least by default).

And g++ regularly fixes language and header conformance issues as bugs,
not treating them as perpetually supported extensions.  The resulting
churn does not seem to have hurt adoption of C++ or g++.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Sam James <sam@gentoo.org>
> Cc: Arsen Arsenović <arsen@aarsen.me>, dave@killthe.net,
>  jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 18:05:09 +0100
> 
> Eli Zaretskii via Gcc <gcc@gcc.gnu.org> writes:
> 
> >> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
> >> Date: Tue, 09 May 2023 18:38:05 +0200
> >> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
> >> 
> >> You're actively dismissing the benefit.
> >
> > Which benefit?
> >
> > 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.
> 
> My email covers this:
> https://gcc.gnu.org/pipermail/gcc/2023-May/241269.html.

If it does, I missed it, even upon second reading now.

Again, the question is: why warning is not enough?

> I'd also note that some of the issues I've seen were already flagged
> in people's CI but they didn't notice because it was just a warning.

The CI can run with non-default flags, if they don't pay attention to
warnings.  If that's the only reason, then I'm sorry, it is not strong
enough.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> 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
reaching the goal, but instead harming those who are well aware of the
warnings.

IOW, if we are targeting people for whom warnings are not enough, then
we have already lost the battle.  Discipline cannot be forced by
technological means, because people will always work around.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

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.

	Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> 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?

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
>> 
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> 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.

Quite simple: people don't (as easily) choose to ignore errors.

You can see this in any teaching environment, and I've had such
experience in many of them, so I can say with an extremely high degree
of confidence that people, by default, do not ignore errors.  A student
will see twenty warnings and brush it off, but will see one error and
diligently go back to fix it.

If we tally up the hypothetical users of the hypothetical -fpermissive
coverage for enabling these broken constructs, I think that we (compiler
and distro developers) will be a supermajority or more.

I am absolutely certain, by virtue of us having this conversation today,
that warnings are not enough.  I am also absolutely certain that an
opt-out error *will* work, as it has before for cases like -fcommon and
the G++ -fpermissive flag (naturally, these aren't magically gone, but
they are becoming rarer).  Hell, I've missed warnings before as they do
not normally raise a flag during development (hence -Werror), even
though I have many years of dealing with loose toolchain defaults.

> That's a simple question, and unless answered with valid arguments,
> the proposal cannot make sense to me, at least.

I'll repeat a few reasons others have cited:
- implicit or misdeclared calls lead to subtly incorrect code,
- implicit calls lead to a lack of toolchain features like
  _FORTIFY_SOURCE,
- implicit calls lead to wrong symbols being chosen, leading to
  data being trimmed, which can on occasion hide itself for a long time,
- all of these constructs have been unambiguously invalid for decades,
- the impact is relatively small (Florian cited a figure of six percent,
  which lines up roughly with my own observation), yet an escape hatch
  for aged code can be easily provided.
- as the compiler is less informed about what code its interfacing in,
  diagnostics are proportionally affected (alongside producing incorrect
  code).
- these constructs have been invalid for decades, and, if considered an
  extension, they're a hideous blot.
- by making GCC not a strict compiler *by default*, we encourage using
  non-GNU toolchains because 'they provide better error reporting'.
  This also applies for other components of the toolchain.  I, for one,
  have little interest in enabling that when the cost for keeping
  fast-and-loose-playing compilers for old (read: broken) codebases is
  low.

It is very much okay (nae, a feature) to be compatible with previous
versions of the compiler, and a prior status quo, but we should not let
it hold us to worse old standards in terms of strictness.

On the contrary, I'd like to hear the upsides of keeping these defaults,
besides compatibility, as that one is easily achieved without keeping
horrid defaults

Have a most lovely evening.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[David Edelsohn]

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

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.

Thanks, David

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


David Edelsohn <dje.gcc@gmail.com> writes:

> This seems to be the core tension.  If developers cared about these issues,
> they would enable appropriate warnings and -Werror.

These issues are easy to miss and overlook.  Making them louder helps
prevent that.

Additionally, requiring the users to remember a dozen flags to make the
compiler strict rather than compatible is just terrible UX.

Today, developers need to both care and know about toolchain oddities to
effectively catch these errors, not just to care.

> 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.

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.

Depending on what exactly you mean by package maintainers, there's
already precedent on how to provide an out (and the OP talks about that
exact topic, too, as it is not something to ignore).
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

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.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Eli Zaretskii via Gcc:

>> 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:
>> > 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?

People completely miss the warning and go to great lengths to show that
what they are dealing is a compiler bug.  (I tried to elaborate on that
in <87cz394b63.fsf@oldenburg.str.redhat.com>.)  If GCC errors out, that
simply does not happen because there is no object code to examine.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Thomas Koenig]

Not replying to anybody in particular, just a bit of history, with
some potential parallels.

In gfortran, we have had two major issues with interfaces.  One was that
code which had happily violated the compiler ABI started failing, due
to a fix in the gfortran front end which meant that we were no longer
mixing varargs and non-varargs calls (which led to code being correctly
compiled for POWER which had been miscompiled for basically forewer).

Among other things, this broke R, and was fixed by Jakub by applying
a workaround.  After a few years, people in core libraries like BLAS
and Netlib are finally getting around to fixing their code.  There is
no knowing what codes still have that, so the workaround will probably
stay around forever, although we don't promise that it does.

Partially motivated by this, we then added a file-level check for
argument list mismatches (type and rank), which issued an error.

That error could be disabled by a new option, -fallow-argument-mismatch,
but that caused problems for people using different versions of the
compiler. So we added this option to -std=legacy, which is a catch-all
kitchen sink, which accepts some not-so-nice things.

Of course, as everybody on this list knows, mixing types like this is
dangerous, and is liable to break sooner or later in future compiler
release. Nonetheless, even a package like MPICH chose to use autoconf
to set the -fallow-argument-mismatch flag rather than fix the code :-(

Others, like the LAPACK maintainers, have reacted and installed
patches.

So... using an error message as a crowbar to change people's behavior
failed, at least partially.  And you only hear from the people who
complain, not from those who are glad that they found errors that they
would otherwise have missed.

What does that mean for the case at hand?  Based on past experience,
I'd lean towards putting all the warnings about the special offending
codes into one warning option (-Wsevere, or something) which could
then be made into an error by -Werror=severe or such variant; maybe
other warnings could be grouped in there as well.  And if these severe
warnings should then be made default or not, well... that (like the
rest of my mail) is open for discussion.

Best regards

	Thomas

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Thomas Koenig via Gcc <gcc@gcc.gnu.org> writes:

> Not replying to anybody in particular, just a bit of history, with
> some potential parallels.
>
> In gfortran, we have had two major issues with interfaces.  One was that
> code which had happily violated the compiler ABI started failing, due
> to a fix in the gfortran front end which meant that we were no longer
> mixing varargs and non-varargs calls (which led to code being correctly
> compiled for POWER which had been miscompiled for basically forewer).
>
> Among other things, this broke R, and was fixed by Jakub by applying
> a workaround.  After a few years, people in core libraries like BLAS
> and Netlib are finally getting around to fixing their code.  There is
> no knowing what codes still have that, so the workaround will probably
> stay around forever, although we don't promise that it does.
>
> Partially motivated by this, we then added a file-level check for
> argument list mismatches (type and rank), which issued an error.
>
> That error could be disabled by a new option, -fallow-argument-mismatch,
> but that caused problems for people using different versions of the
> compiler. So we added this option to -std=legacy, which is a catch-all
> kitchen sink, which accepts some not-so-nice things.
>
> Of course, as everybody on this list knows, mixing types like this is
> dangerous, and is liable to break sooner or later in future compiler
> release. Nonetheless, even a package like MPICH chose to use autoconf
> to set the -fallow-argument-mismatch flag rather than fix the code :-(
>
> Others, like the LAPACK maintainers, have reacted and installed
> patches.
>
> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.
>
> What does that mean for the case at hand?  Based on past experience,
> I'd lean towards putting all the warnings about the special offending
> codes into one warning option (-Wsevere, or something) which could
> then be made into an error by -Werror=severe or such variant; maybe
> other warnings could be grouped in there as well.  And if these severe
> warnings should then be made default or not, well... that (like the
> rest of my mail) is open for discussion.

I don't see permitting this code by default as providing any benefit,
even in a world in which we presume everyone passes -fpermissive or
such.

We should not make the default loose.  It is worse for the average
responsible developer to carry a heap of flags than it is for the
occasional irresponsible one (or a person dealing with legacy code) to
carry a single flag (or even a couple).

I can't speak on how close this is to how people will behave when
dealing with C, as I have minimal Fortran experience, but I am decently
sure that, unambiguously, these mistakes are entirely unwanted in C,
without significant upside, and so, I'm optimistic that any maintained
piece of code will soon get rid of them as a result of increasing
strictenss in GCC.

(again, this line of thought excludes the upside of compatibility with
old code as that is not particularly hard to achieve, and so I feel it
doesn't need to be considered)

> Best regards
>
> 	Thomas

Thank you for your insight, have a lovely evening.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[David Edelsohn]

[-- 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

Re: More C type errors by default for GCC 14

[Joel Sherrill]

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

On Tue, May 9, 2023 at 5:28 PM David Edelsohn via Gcc <gcc@gcc.gnu.org>
wrote:

> 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.
>

Well said.

I know over at RTEMS, we have been using GCC since before EGCS and
during that time, we have upgraded our GCC version a lot of times. Often,
the upgrade generates more warnings. We accept that as a benefit and
cost of having a living project. We also may be on the more precise end
of the scale in specifying our GCC arguments.  We specify the language
version, enable as many warnings as possible, etc. I think it is critical
that
a project pick their language version and ensure that they are not
getting the default which shifts over time.

We are currently using gcc 12 and specifying C11.  To experiment with
these stricter warnings and slowly address them, would we need to build
with a newer C version?

What practices might the GCC community recommend to a project
wanting to discover the issues uncovered and slowly address them? I
i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
where the improved strict alias checking gave us a LOT of warnings to
deal with and it felt overwhelming. I don't want to do that again.

But I believe in letting the compiler get stricter and find things.
Defaulting
to stricter checking is a good thing.

--joel sherrill
RTEMS

>
> Thanks, David
>

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> We are currently using gcc 12 and specifying C11.  To experiment with
> these stricter warnings and slowly address them, would we need to build
> with a newer C version?

No, the proposed changes are to give errors (instead of warnings) for
rules introduced in C99. GCC is just two decades late in enforcing the
C99 rules properly!


> What practices might the GCC community recommend to a project
> wanting to discover the issues uncovered and slowly address them? I

-Werror=implicit-int
-Werror=implicit-function-declaration
-Werror=int-conversion

> i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
> where the improved strict alias checking gave us a LOT of warnings to
> deal with and it felt overwhelming. I don't want to do that again.
>
> But I believe in letting the compiler get stricter and find things. Defaulting
> to stricter checking is a good thing.

The checks are already done, they're just warnings by default, and so
easily missed/ignored when compiling large code bases.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Jakub Jelinek <jakub@redhat.com>,  Eli Zaretskii <eliz@gnu.org>,
>   jwakely.gcc@gmail.com,  arsen@aarsen.me
> Date: Tue, 09 May 2023 22:57:20 +0200
> 
> * Eli Zaretskii via Gcc:
> 
> >> 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:
> >> > 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?
> 
> People completely miss the warning and go to great lengths to show that
> what they are dealing is a compiler bug.  (I tried to elaborate on that
> in <87cz394b63.fsf@oldenburg.str.redhat.com>.)  If GCC errors out, that
> simply does not happen because there is no object code to examine.

And then people will start complaining about GCC unnecessarily
erroring out, which is a compiler bug, since there's no problem
producing correct code in these cases.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
>  jwakely.gcc@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.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Wed, 10 May 2023, 03:32 Eli Zaretskii, <eliz@gnu.org> wrote:

>
> And then people will start complaining about GCC unnecessarily
> erroring out, which is a compiler bug, since there's no problem
> producing correct code in these cases.
>


What is the correct code for this?

void foo(int);
void bar() { foo("42"); }

Why should this compile?

You keep demanding better rationale for the change, but your argument
amounts to nothing more than "it compiles today, it should compile
tomorrow".

>

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Eli Zaretskii <eliz@gnu.org> writes:

> It is not GCC's business to force developers of packages to get their
> act together.

Why not?  Compilers are diagnostic tools besides just machines that
guess what machine code you mean.

> 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.

There's a difference between dubious and unsafe code and code that is
unambiguously wrong, but was chosen to be accepted many years ago.

> 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.

Producing call code with wrong prototypes is not within my definition of
producing valid code.

> 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.

Please see the various porting-to pages.  Compilers stop being able to
produce code with older versions of programs because of them being a
lil' too lax and the programs accidentally relying on that every year.
There's nothing wrong there.

If compilers stopped being lax, such things wouldn't happen simply
because programs couldn't accidentally rely on it, so we'd get the ideal
world without breakages.  We don't get that by pretending code is fine
when it is not, and letting developers write that code.

Now, of course, this instance is different to porting-to pages, because
we aren't talking about code accidentally relying on a transitive
include or an edge case or somesuch, we're talking about the compiler
going out of its way to produce wrong code and whispering into the wind
about doing it.

> 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.

It would be a grave mistake on the part of GCC to decide that part of
its mission is to pretend code is fine when it is unambiguously broken,
and then not tell people about it very loudly.

I don't think we should send out the message of "GCC: the compiler for
your untouchable legacy code, not for writing new code, or upgrading
existing code".

Providing compatibility here is a trivial job, we don't need to make
each developer suffer with tweaking compiler flags to get the compiler
to diagnose blatantly wrong code as errors, or more likely, not do it at
all because they don't know about this problem.

We could, of course, alter documentation to tell people that running GCC
in strict mode requires some concoction of flags, or we could alter it
so that it says that running GCC in a lax mode requires *one* flag, for
the exceptional case where code can't be easily fixed, and it's more
useful to pretend it's fine and emit broken calls.

We could even provide a 'laxgcc' or such driver that covers this
exceptional case OOTB (though I'm unconvinced that does anything that
setting CC='gcc -fpermissive' doesn't cover).

Have a lovely day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Richard Biener]

On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc
<gcc@gcc.gnu.org> wrote:
>
> On Wed, 10 May 2023, 03:32 Eli Zaretskii, <eliz@gnu.org> wrote:
>
> >
> > And then people will start complaining about GCC unnecessarily
> > erroring out, which is a compiler bug, since there's no problem
> > producing correct code in these cases.
> >
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?
>
> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".

void foo(__UINTPTR_TYPE__);
void bar() { foo("42"); }

might be something we'd still like to diagnose but eventually not turn
into an error?  Yes, it then depends on the target whether the code is
accepted or not, but at least it would continue working where there's
a "good" answer to your question.

Probably splitting hairs here ..

Richard.
>
> >

Re: More C type errors by default for GCC 14

[David Brown]

On 09/05/2023 21:04, 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
> reaching the goal, but instead harming those who are well aware of the
> warnings.
> 

My experience is that many of the people who ignore warnings are not 
particularly good developers, and not particularly good at 
self-improvement.  They know how to ignore warnings - the attitude is 
"if it really was a problem, the compiler would have given an error 
message, not a mere warning".  They don't know how to disable error 
messages, and won't bother to find out.  So they will, in fact, be a lot 
more likely to fix their code.


> IOW, if we are targeting people for whom warnings are not enough, then
> we have already lost the battle.  Discipline cannot be forced by
> technological means, because people will always work around.
> 

Agreed.  But if we can make it harder for them to release bad code, 
that's good overall.

Ideally, I'd like the compiler to email such people's managers with a 
request that they be sent on programming courses!

Re: More C type errors by default for GCC 14

[Eric Gallager]

On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>> We are currently using gcc 12 and specifying C11.  To experiment with
>> these stricter warnings and slowly address them, would we need to build
>> with a newer C version?
>
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!
>
>
>> What practices might the GCC community recommend to a project
>> wanting to discover the issues uncovered and slowly address them? I
>
> -Werror=implicit-int
> -Werror=implicit-function-declaration
> -Werror=int-conversion
>

Idea for a compromise: What if, instead of flipping the switch on all
3 of these at once, we staggered them so that each one becomes a
default in a separate release? i.e., something like:

- GCC 14: -Werror=implicit-function-declaration gets added to the defaults
- GCC 15: -Werror=implicit-int gets added to the defaults
- GCC 16: -Werror=int-conversion gets added to the defaults

That would give people more time to catch up on a particular warning,
rather than overwhelming them with a whole bunch all at once. Just an
idea.

>> i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
>> where the improved strict alias checking gave us a LOT of warnings to
>> deal with and it felt overwhelming. I don't want to do that again.
>>
>> But I believe in letting the compiler get stricter and find things.
>> Defaulting
>> to stricter checking is a good thing.
>
> The checks are already done, they're just warnings by default, and so
> easily missed/ignored when compiling large code bases.
>

Re: More C type errors by default for GCC 14

[Sam James]

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


Eric Gallager via Gcc <gcc@gcc.gnu.org> writes:

> On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>>> We are currently using gcc 12 and specifying C11.  To experiment with
>>> these stricter warnings and slowly address them, would we need to build
>>> with a newer C version?
>>
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>>
>>
>>> What practices might the GCC community recommend to a project
>>> wanting to discover the issues uncovered and slowly address them? I
>>
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>> -Werror=int-conversion
>>
>
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
>
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
>
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

I think this might be more frustrating than not, althuogh I appreciate
the intent.

Neal Gompa wasn't keen on the idea at
https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
because it'd feel like essentially "repeated punches".

Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
implicit-function-declaration,implicit-int (these are so closely related
that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
incompatible-pointer-types. But spreading it out too much is likely counterproductive.

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

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 11:40, Eric Gallager <egall@gwmail.gwu.edu> wrote:
>
> On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> >> We are currently using gcc 12 and specifying C11.  To experiment with
> >> these stricter warnings and slowly address them, would we need to build
> >> with a newer C version?
> >
> > No, the proposed changes are to give errors (instead of warnings) for
> > rules introduced in C99. GCC is just two decades late in enforcing the
> > C99 rules properly!
> >
> >
> >> What practices might the GCC community recommend to a project
> >> wanting to discover the issues uncovered and slowly address them? I
> >
> > -Werror=implicit-int
> > -Werror=implicit-function-declaration
> > -Werror=int-conversion
> >
>
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
>
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
>
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

On the Suse list there was a strong objection to doing that, because
it just prolongs the pain. It means maintainers spend the next three
years dealing with it, fixing the same packages again and again,
instead of just getting it done.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 11:48, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 10 May 2023 at 11:40, Eric Gallager <egall@gwmail.gwu.edu> wrote:
> >
> > On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> > > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > >> We are currently using gcc 12 and specifying C11.  To experiment with
> > >> these stricter warnings and slowly address them, would we need to build
> > >> with a newer C version?
> > >
> > > No, the proposed changes are to give errors (instead of warnings) for
> > > rules introduced in C99. GCC is just two decades late in enforcing the
> > > C99 rules properly!
> > >
> > >
> > >> What practices might the GCC community recommend to a project
> > >> wanting to discover the issues uncovered and slowly address them? I
> > >
> > > -Werror=implicit-int
> > > -Werror=implicit-function-declaration
> > > -Werror=int-conversion
> > >
> >
> > Idea for a compromise: What if, instead of flipping the switch on all
> > 3 of these at once, we staggered them so that each one becomes a
> > default in a separate release? i.e., something like:
> >
> > - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> > - GCC 15: -Werror=implicit-int gets added to the defaults
> > - GCC 16: -Werror=int-conversion gets added to the defaults
> >
> > That would give people more time to catch up on a particular warning,
> > rather than overwhelming them with a whole bunch all at once. Just an
> > idea.
>
> On the Suse list there was a strong objection to doing that, because
> it just prolongs the pain. It means maintainers spend the next three
> years dealing with it, fixing the same packages again and again,
> instead of just getting it done.

And if you don't want to deal with them all, just use the -fpermissive
flag (or however it will be named) to get the old behaviour.

I really don't see how dragging this out over **another** three years
will help anybody. Florian's already been working on this for years.

Re: More C type errors by default for GCC 14

[Neal Gompa]

On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
>
>
> Eric Gallager via Gcc <gcc@gcc.gnu.org> writes:
>
> > On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> >>> We are currently using gcc 12 and specifying C11.  To experiment with
> >>> these stricter warnings and slowly address them, would we need to build
> >>> with a newer C version?
> >>
> >> No, the proposed changes are to give errors (instead of warnings) for
> >> rules introduced in C99. GCC is just two decades late in enforcing the
> >> C99 rules properly!
> >>
> >>
> >>> What practices might the GCC community recommend to a project
> >>> wanting to discover the issues uncovered and slowly address them? I
> >>
> >> -Werror=implicit-int
> >> -Werror=implicit-function-declaration
> >> -Werror=int-conversion
> >>
> >
> > Idea for a compromise: What if, instead of flipping the switch on all
> > 3 of these at once, we staggered them so that each one becomes a
> > default in a separate release? i.e., something like:
> >
> > - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> > - GCC 15: -Werror=implicit-int gets added to the defaults
> > - GCC 16: -Werror=int-conversion gets added to the defaults
> >
> > That would give people more time to catch up on a particular warning,
> > rather than overwhelming them with a whole bunch all at once. Just an
> > idea.
>
> I think this might be more frustrating than not, althuogh I appreciate
> the intent.
>
> Neal Gompa wasn't keen on the idea at
> https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> because it'd feel like essentially "repeated punches".
>
> Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> implicit-function-declaration,implicit-int (these are so closely related
> that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> incompatible-pointer-types. But spreading it out too much is likely counterproductive.

Right, we've been going through a similar effort with C++ over the
past decade. GCC incrementally becoming more strict on C++ has been an
incredibly painful experience, and it eats away a ton of time that I
would have spent dealing with other problems. Having one big event
where the majority of changes to make the C compiler strict happen
will honestly make it less painful, even if it doesn't seem like it at
the moment.

This is because with as much C++ stuff we have in Linux distributions,
we have so much more C stuff.



--
真実はいつも一つ！/ Always, there's only one truth!

Re: More C type errors by default for GCC 14

[David Brown]

On 09/05/2023 22:13, David Edelsohn via Gcc 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.
> 

-Werror is a /big/ stick.  An unused parameter message might just be an 
indication that the programmer isn't finished with that bit of code, and 
a warning is fine.  An implicit function declaration message shows a 
clear problem in the code - a typo in the function call, a missing 
#include, or a major flaw in the design and organisation of the code.

The C language takes backwards compatibility more seriously than any 
other programming language.  When the C standards mark previously 
acceptable features as deprecated, obsolescent, or constrain errors, it 
is done for very good reasons.  People should not be writing code with 
implicit int, or non-prototype function declarations.  Such mis-features 
of the language were outdated 30 years ago.

> 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.
> 

There are two problems I see with the current state of affairs, where 
deeply flawed code can be accepted (possibly with warnings) by gcc by 
default.

1. Modern developers who are not particularly well versed in the 
language write code with these same risky features.  It is depressing 
how many people think "The C Programming Language" (often a battered 
first edition) is all you need for learning C programming.  Turning more 
outdated syntax and more obvious mistakes into hard errors will help 
such developers - and help everyone who has to use the code they make.


2. Old code gets compiled with with modern tools that do not fulfil the 
assumptions made by the developer decades ago.  Compiling such code with 
modern gcc risks all sorts of problems due to the simpler compilation 
models of older tools.  For example, the code might assume two's 
complement wrapping arithmetic, or that function calls always act as a 
memory barrier.


My suggestion would be to have a flag "-fold-code" that would do the 
following (at a minimum) :

* Disallow higher optimisation flags.
* Force -fwrapv, -fno-strict-aliasing, -fno-inline.
* Require an explicit "-std=" selection.
* Allow old-style syntax, such as implicit int, with just a warning

If the "-fold-code" is /not/ included, then old, deprecated or 
obsolescent syntax would be a hard error that cannot be turned off or 
downgraded to a warning by flags.  A substantial subset of -Wall 
warnings would be enabled automatically.  (I think the "unused" warnings 
should not be included, for example.)


Distributions and upstream code maintainers should be pushed towards 
either fixing and updating their code, or marking it as "-fold-code" if 
it is too outdated to modernise without a major re-write.  This might be 
painful during the transition, but waiting longer just makes the 
situation work.

(I'm a long-term gcc user, but not a gcc developer.  I'm fully aware 
that I am asking others to do a lot of work here, but I think something 
of this sort is important going forward.)


David

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Wed, 10 May 2023 09:04:12 +0100
> Cc: Florian Weimer <fweimer@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, 
> 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>
> 
> void foo(int);
> void bar() { foo("42"); }
> 
> Why should this compile?

Because GCC is capable of compiling it.

> You keep demanding better rationale for the change, but your argument amounts to nothing more than
> "it compiles today, it should compile tomorrow".

It compiles today with a warning, so that whoever is interested to fix
the code, can do that already.  The issue at hand is not whether to
flag the code as highly suspicious, the issue at hand is whether
upgrade the warning to errors.  So let's talk about the issue at hand,
not about something else, okay?

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 10:49:32 +0200
> From: David Brown via Gcc <gcc@gcc.gnu.org>
> 
> > People who ignore warnings will use options that disable these new
> > errors, exactly as they disable warnings.  So we will end up not
> > reaching the goal, but instead harming those who are well aware of the
> > warnings.
> 
> My experience is that many of the people who ignore warnings are not 
> particularly good developers, and not particularly good at 
> self-improvement.  They know how to ignore warnings - the attitude is 
> "if it really was a problem, the compiler would have given an error 
> message, not a mere warning".  They don't know how to disable error 
> messages, and won't bother to find out.  So they will, in fact, be a lot 
> more likely to fix their code.

If some developers want to ignore warnings, it is not the business of
GCC to improve them, even if you are right in assuming that they will
not work around errors like they work around warnings (and I'm not at
all sure you are right in that assumption).  But by _forcing_ these
errors on _everyone_, GCC will in effect punish those developers who
have good reasons for not changing the code.

> > IOW, if we are targeting people for whom warnings are not enough, then
> > we have already lost the battle.  Discipline cannot be forced by
> > technological means, because people will always work around.
> > 
> 
> Agreed.  But if we can make it harder for them to release bad code, 
> that's good overall.

I'm okay with making it harder, but without making it too hard for
those whose reasons for not changing the code are perfectly valid.
This proposal crosses that line, IMNSHO.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 12:36, Eli Zaretskii via Gcc <gcc@gcc.gnu.org> wrote:
>
> > Date: Wed, 10 May 2023 10:49:32 +0200
> > From: David Brown via Gcc <gcc@gcc.gnu.org>
> >
> > > People who ignore warnings will use options that disable these new
> > > errors, exactly as they disable warnings.  So we will end up not
> > > reaching the goal, but instead harming those who are well aware of the
> > > warnings.
> >
> > My experience is that many of the people who ignore warnings are not
> > particularly good developers, and not particularly good at
> > self-improvement.  They know how to ignore warnings - the attitude is
> > "if it really was a problem, the compiler would have given an error
> > message, not a mere warning".  They don't know how to disable error
> > messages, and won't bother to find out.  So they will, in fact, be a lot
> > more likely to fix their code.
>
> If some developers want to ignore warnings, it is not the business of
> GCC to improve them, even if you are right in assuming that they will
> not work around errors like they work around warnings (and I'm not at
> all sure you are right in that assumption).  But by _forcing_ these
> errors on _everyone_, GCC will in effect punish those developers who
> have good reasons for not changing the code.

There will be options you can use to continue compiling the code
without changing it. You haven't given a good reason why it's OK for
one group of developers to have to use options to get their desired
behaviour from GCC, but completely unacceptable for a different group
to have to use options to get their desired behaviour.

This is just a change in defaults. Accepting broken code by default is
not a priori a good thing, as you seem to insist. Rejecting it by
default is not a priori a good thing. There is a pragmatic choice to
be made, and your argument is still no more than "it compiles today,
so it should compile tomorrow".


> > > IOW, if we are targeting people for whom warnings are not enough, then
> > > we have already lost the battle.  Discipline cannot be forced by
> > > technological means, because people will always work around.
> > >
> >
> > Agreed.  But if we can make it harder for them to release bad code,
> > that's good overall.
>
> I'm okay with making it harder, but without making it too hard for
> those whose reasons for not changing the code are perfectly valid.
> This proposal crosses that line, IMNSHO.

Where "too hard" means using a compiler option. Seriously? This seems farcical.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 10:36:23 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is not GCC's business to force developers of packages to get their
> > act together.
> 
> Why not?  Compilers are diagnostic tools besides just machines that
> guess what machine code you mean.

Diagnostics does not mean error.  A warning is also diagnostics.

> > 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.
> 
> There's a difference between dubious and unsafe code and code that is
> unambiguously wrong, but was chosen to be accepted many years ago.

Is GCC indeed capable of reliably distinguishing between these two?

And that code is not unambiguously wrong, since it is valid under old
standards, and thus can be compiled, and did compile, into a working
program.

> > 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.
> 
> Producing call code with wrong prototypes is not within my definition of
> producing valid code.

I don't think I follow.  If the produced machine code is valid and
does what the programmer meant, why should we care about the
prototypes?

> > 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.
> 
> Please see the various porting-to pages.  Compilers stop being able to
> produce code with older versions of programs because of them being a
> lil' too lax and the programs accidentally relying on that every year.
> There's nothing wrong there.
> 
> If compilers stopped being lax, such things wouldn't happen simply
> because programs couldn't accidentally rely on it, so we'd get the ideal
> world without breakages.  We don't get that by pretending code is fine
> when it is not, and letting developers write that code.

Once again, it is not GCC's business to clean up the packages which
use GCC as the compiler.  GCC is a tool, and should allow any
legitimate use of it that could be useful to someone.  Warning about
dubious usage is perfectly fine, as it helps those who do that
unintentionally or due to ignorance.  But completely failing an
operation that could have produce valid code is too radical.

We all want that the code of the packages be clean and according to
standards.  But using draconian measures towards that goal is dead
wrong, and is basically against the libertarian spirit that gave birth
to Free Software.  It is not an accident that GPL doesn't disallow
writing badly written or even crashing programs.

> > 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.
> 
> It would be a grave mistake on the part of GCC to decide that part of
> its mission is to pretend code is fine when it is unambiguously broken,
> and then not tell people about it very loudly.

It is not broken, certainly not "unambiguously".  It did compile and
work in the very recent past.

> I don't think we should send out the message of "GCC: the compiler for
> your untouchable legacy code, not for writing new code, or upgrading
> existing code".

GCC sends the messages "don't write bad or dubious code" by emitting
warnings about such code.  There's no need to have a virtual gun
pointed to the heads of package developers to make that message so
much stronger, because doing that shifts the balance from merely being
a good and friendly tool towards second-guessing all of the GCC users
and knowing better then they do what they want.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> Once again, it is not GCC's business to clean up the packages which
> use GCC as the compiler.  GCC is a tool, and should allow any
> legitimate use of it that could be useful to someone.  Warning about
> dubious usage is perfectly fine, as it helps those who do that
> unintentionally or due to ignorance.  But completely failing an
> operation that could have produce valid code is too radical.

Again (are you even reading the replies?), there will be an option to
continue to accept the invalid code. This is just a change in
defaults.

GCC will not force anybody to change code, at most it this change
would force them to consciously and intentionally say "I know this is
not valid C code but I want to compile it anyway". By using a compiler
option. This is not draconian, and you sound quite silly.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Eric Gallager <egall@gwmail.gwu.edu>
> Date: Wed, 10 May 2023 06:40:54 -0400
> Cc: joel@rtems.org, David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
> 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>, 
> 	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> 
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
> 
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
> 
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

What do we tell those who cannot possibly "catch up", for whatever
valid reasons?  E.g., consider a program written many years ago, which
is safety-critical, and where making any changes requires so many
validations and verifications that it is simply impractical, and will
never be done.  Why would we want to break such programs?

And that is just one example of perfectly valid reasons for not
wanting or not being able to make changes to pacify GCC.

Once again, my bother is not about "villains" who don't want to get
their act together, my bother is about cases such as the one above,
where the developers simply have no practical choice.

And please don't tell me they should use an older GCC, because as
systems go forward and are upgraded, older GCC will not work anymore.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote:
> > From: Jonathan Wakely <jwakely.gcc@gmail.com>
> > Date: Wed, 10 May 2023 09:04:12 +0100
> > Cc: Florian Weimer <fweimer@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, 
> > 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>
> > 
> > void foo(int);
> > void bar() { foo("42"); }
> > 
> > Why should this compile?
> 
> Because GCC is capable of compiling it.

That is not a good argument.  GCC is capable of compiling any code in all
the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
mean those bugs shouldn't be fixed.

C99 for the above says:
6.5.2.2/7
"If the expression that denotes the called function has a type that does include a prototype,
the arguments are implicitly converted, as if by assignment, to the types of the
corresponding parameters, taking the type of each parameter to be the unqualified version
of its declared type."
and
"One of the following shall hold:
— the left operand has qualified or unqualified arithmetic type and the right has
arithmetic type;
— the left operand has a qualified or unqualified version of a structure or union type
compatible with the type of the right;
— both operands are pointers to qualified or unqualified versions of compatible types,
and the type pointed to by the left has all the qualifiers of the type pointed to by the
right;
— one operand is a pointer to an object or incomplete type and the other is a pointer to a
qualified or unqualified version of void, and the type pointed to by the left has all
the qualifiers of the type pointed to by the right;
— the left operand is a pointer and the right is a null pointer constant; or
— the left operand has type _Bool and the right is a pointer."
For the above case, none of that holds and it isn't something desirable to
be supported as GNU extension, because while it could happen to work as the
user wanted after cast back to pointer in foo on ilp32 architectures, it
doesn't make any sense on lp64 or llp64 architectures.

Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.
The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

> It compiles today with a warning, so that whoever is interested to fix
> the code, can do that already.  The issue at hand is not whether to
> flag the code as highly suspicious, the issue at hand is whether
> upgrade the warning to errors.  So let's talk about the issue at hand,
> not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.
A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

	Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org, 
> 	David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>, 
> 	Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org, 
> 	c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> >
> > Neal Gompa wasn't keen on the idea at
> > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > because it'd feel like essentially "repeated punches".
> >
> > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> > implicit-function-declaration,implicit-int (these are so closely related
> > that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> > incompatible-pointer-types. But spreading it out too much is likely counterproductive.
> 
> Right, we've been going through a similar effort with C++ over the
> past decade. GCC incrementally becoming more strict on C++ has been an
> incredibly painful experience, and it eats away a ton of time that I
> would have spent dealing with other problems. Having one big event
> where the majority of changes to make the C compiler strict happen
> will honestly make it less painful, even if it doesn't seem like it at
> the moment.

But not having such an event, ever, would be even less painful.

Re: More C type errors by default for GCC 14

[Neal Gompa]

On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Neal Gompa <neal@gompa.dev>
> > Date: Wed, 10 May 2023 06:56:32 -0400
> > Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org,
> >       David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
> >       Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org,
> >       c-std-porting@lists.linux.dev
> >
> > On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> > >
> > > Neal Gompa wasn't keen on the idea at
> > > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > > because it'd feel like essentially "repeated punches".
> > >
> > > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> > > implicit-function-declaration,implicit-int (these are so closely related
> > > that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> > > incompatible-pointer-types. But spreading it out too much is likely counterproductive.
> >
> > Right, we've been going through a similar effort with C++ over the
> > past decade. GCC incrementally becoming more strict on C++ has been an
> > incredibly painful experience, and it eats away a ton of time that I
> > would have spent dealing with other problems. Having one big event
> > where the majority of changes to make the C compiler strict happen
> > will honestly make it less painful, even if it doesn't seem like it at
> > the moment.
>
> But not having such an event, ever, would be even less painful.

That's not going to happen. An event will eventually happen when GCC
and Clang switch their default C standard version. And making the
compilers stricter is something that has enough benefit to outweigh
the pain. The question is "how often" rather than "should we do it".



--
真実はいつも一つ！/ Always, there's only one truth!

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Wed, 10 May 2023 12:49:52 +0100
> Cc: David Brown <david@westcontrol.com>, gcc@gcc.gnu.org
> 
> > If some developers want to ignore warnings, it is not the business of
> > GCC to improve them, even if you are right in assuming that they will
> > not work around errors like they work around warnings (and I'm not at
> > all sure you are right in that assumption).  But by _forcing_ these
> > errors on _everyone_, GCC will in effect punish those developers who
> > have good reasons for not changing the code.
> 
> There will be options you can use to continue compiling the code
> without changing it. You haven't given a good reason why it's OK for
> one group of developers to have to use options to get their desired
> behaviour from GCC, but completely unacceptable for a different group
> to have to use options to get their desired behaviour.
> 
> This is just a change in defaults.

A change in defaults that is not backward-compatible should only be
done for very good reasons, because it breaks something that was
working for years.  No such good reasons were provided.  And no,
educating/forcing GCC users to use more modern dialect of C is not a
good reason.

> Accepting broken code by default is not a priori a good thing, as
> you seem to insist. Rejecting it by default is not a priori a good
> thing. There is a pragmatic choice to be made, and your argument is
> still no more than "it compiles today, so it should compile
> tomorrow".

Once again: it isn't "broken code".  It is dangerous code, and in some
cases unintentionally suspicious code.  But it isn't broken, because
GCC can compile it into a valid program, which, if the programmer
indeed meant that, will work and do its job.

> > > Agreed.  But if we can make it harder for them to release bad code,
> > > that's good overall.
> >
> > I'm okay with making it harder, but without making it too hard for
> > those whose reasons for not changing the code are perfectly valid.
> > This proposal crosses that line, IMNSHO.
> 
> Where "too hard" means using a compiler option. Seriously? This seems farcical.

This goes both ways, of course.  GCC had -Werror since about forever.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Wed, 10 May 2023 12:56:48 +0100
> Cc: Arsen Arsenović <arsen@aarsen.me>, dje.gcc@gmail.com, 
> 	jakub@redhat.com, gcc@gcc.gnu.org
> 
> On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> > Once again, it is not GCC's business to clean up the packages which
> > use GCC as the compiler.  GCC is a tool, and should allow any
> > legitimate use of it that could be useful to someone.  Warning about
> > dubious usage is perfectly fine, as it helps those who do that
> > unintentionally or due to ignorance.  But completely failing an
> > operation that could have produce valid code is too radical.
> 
> Again (are you even reading the replies?)

Please assume that I read everything, subject to email delivery times.
There's no reason for you to assume anything but good faith from my
side.

> GCC will not force anybody to change code, at most it this change
> would force them to consciously and intentionally say "I know this is
> not valid C code but I want to compile it anyway". By using a compiler
> option. This is not draconian, and you sound quite silly.

If we are not forcing code change, why bother with making it an error
at all?  The only reason for doing so that was provided was that this
_is_ a way of forcing people to change their programs.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Richard Biener:

> On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc
> <gcc@gcc.gnu.org> wrote:
>>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii, <eliz@gnu.org> wrote:
>>
>> >
>> > And then people will start complaining about GCC unnecessarily
>> > erroring out, which is a compiler bug, since there's no problem
>> > producing correct code in these cases.
>> >
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>>
>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> void foo(__UINTPTR_TYPE__);
> void bar() { foo("42"); }
>
> might be something we'd still like to diagnose but eventually not turn
> into an error?  Yes, it then depends on the target whether the code is
> accepted or not, but at least it would continue working where there's
> a "good" answer to your question.

The x86-64 defaults for GNU/Linux were originally set in such a way that
there is a good chance that pointers fit into an int, and broken code
like that happens to work (as long as it's in the main program).  Of
course I think we should nevertheless reject it by default.

Anyway, if int-conversion somehow proves more controversial, I believe
disabling implicit-int and implicit-function-declaration by default
would still be a huge step forward.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Jonathan Wakely <jwakely.gcc@gmail.com>
> > Date: Wed, 10 May 2023 12:56:48 +0100
> > Cc: Arsen Arsenović <arsen@aarsen.me>, dje.gcc@gmail.com,
> >       jakub@redhat.com, gcc@gcc.gnu.org
> >
> > On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> > > Once again, it is not GCC's business to clean up the packages which
> > > use GCC as the compiler.  GCC is a tool, and should allow any
> > > legitimate use of it that could be useful to someone.  Warning about
> > > dubious usage is perfectly fine, as it helps those who do that
> > > unintentionally or due to ignorance.  But completely failing an
> > > operation that could have produce valid code is too radical.
> >
> > Again (are you even reading the replies?)
>
> Please assume that I read everything, subject to email delivery times.
> There's no reason for you to assume anything but good faith from my
> side.
>
> > GCC will not force anybody to change code, at most it this change
> > would force them to consciously and intentionally say "I know this is
> > not valid C code but I want to compile it anyway". By using a compiler
> > option. This is not draconian, and you sound quite silly.
>
> If we are not forcing code change, why bother with making it an error
> at all?  The only reason for doing so that was provided was that this
> _is_ a way of forcing people to change their programs.

It stops people writing these errors in the first place. Not all code
compiled with GCC is old, crufty K&R code that must be preserved for
eternity.

People are still using C to write new programs, and they are still
making avoidable mistakes. The default for new code using new -std
modes should be safer and less error prone.

Re: More C type errors by default for GCC 14

[Sam James]

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


Eli Zaretskii via Gcc <gcc@gcc.gnu.org> writes:

>> Date: Wed, 10 May 2023 10:49:32 +0200
>> From: David Brown via Gcc <gcc@gcc.gnu.org>
>> 
>> > People who ignore warnings will use options that disable these new
>> > errors, exactly as they disable warnings.  So we will end up not
>> > reaching the goal, but instead harming those who are well aware of the
>> > warnings.
>> 
>> My experience is that many of the people who ignore warnings are not 
>> particularly good developers, and not particularly good at 
>> self-improvement.  They know how to ignore warnings - the attitude is 
>> "if it really was a problem, the compiler would have given an error 
>> message, not a mere warning".  They don't know how to disable error 
>> messages, and won't bother to find out.  So they will, in fact, be a lot 
>> more likely to fix their code.
>
> If some developers want to ignore warnings, it is not the business of
> GCC to improve them, even if you are right in assuming that they will
> not work around errors like they work around warnings (and I'm not at
> all sure you are right in that assumption).  But by _forcing_ these
> errors on _everyone_, GCC will in effect punish those developers who
> have good reasons for not changing the code.
>
>> > IOW, if we are targeting people for whom warnings are not enough, then
>> > we have already lost the battle.  Discipline cannot be forced by
>> > technological means, because people will always work around.
>> > 
>> 
>> Agreed.  But if we can make it harder for them to release bad code, 
>> that's good overall.
>
> I'm okay with making it harder, but without making it too hard for
> those whose reasons for not changing the code are perfectly valid.
> This proposal crosses that line, IMNSHO.

Could you give an example of how to make it harder without crossing
the line for you?

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

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 14:03:01 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, fweimer@redhat.com,
>         gcc@gcc.gnu.org, arsen@aarsen.me
> 
> > > Why should this compile?
> > 
> > Because GCC is capable of compiling it.
> 
> That is not a good argument.  GCC is capable of compiling any code in all
> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> mean those bugs shouldn't be fixed.

Fixing those bugs, if they are bugs, is not the job of the compiler.
It's the job of the programmer, who is the one that knows what the
code was supposed to do.  If there's a significant risk that the code
is a mistake or might behave in problematic ways, a warning to that
effect is more than enough.

> C99 for the above says:

I know what the standard says, but since when do we in the GNU project
accept standards as a dictate?  We do what we consider to be best for
our users, and follow the standards when that doesn't contradict what
we think is best for the users.  GCC has, for example, -std=gnu99
etc. precisely for that purpose.

> The proposal is essentially to stop accepting this as a GNU extension
> which was added for K&R compatibility I assume and do that only for C99 and
> later.

I understand.  I'm saying that there's no reason to make this an
error, because it will break builds that have good reasons for keeping
such code.

> Note, this isn't valid even in C89 and is already rejected with
> -pedantic-errors for years.

Terrific!  Rejecting such code given a non-default option is _exactly_
what should be done.  But we here are discussing the default behavior.

> > It compiles today with a warning, so that whoever is interested to fix
> > the code, can do that already.  The issue at hand is not whether to
> > flag the code as highly suspicious, the issue at hand is whether
> > upgrade the warning to errors.  So let's talk about the issue at hand,
> > not about something else, okay?
> 
> We do such changes several times a year, where we reject something that has
> been previously accepted in older standards, admittedly mostly in C++.

And that is a Good Thing?  I don't think so.  Maybe for C++ it's
inevitable, I'm not an expert on that.  But making breaking changes is
inherently BAD and should be avoided.

> Yes, it is done far less in C, but still, as the above is invalid already in
> C89, users had over 3 decades to fix their code, and in many cases they
> didn't and without this move they will never bother.

Please consider those cases where the code cannot be "fixed", in
practice.  I described one such situation in a previous message.

> A lot of such broken code has been even written in those 3 decades, doesn't
> predate it, but because the compiler just warned on it, it still appeared in
> the code bases.  If we wait with this change another 2 decades, nothing will
> change and we'll have the same problem then.

GCC is not responsible for the existence of that code.  So GCC
shouldn't change its decades-long behavior just because that code is
there.  there must be a much more serious reason for such changes,
something that affects GCC itself.

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/10/23 14:36, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 14:03:01 +0200
>> From: Jakub Jelinek <jakub@redhat.com>
>> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, fweimer@redhat.com,
>>          gcc@gcc.gnu.org, arsen@aarsen.me
>>
>>>> Why should this compile?
>>> Because GCC is capable of compiling it.
>> That is not a good argument.  GCC is capable of compiling any code in all
>> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
>> mean those bugs shouldn't be fixed.
> Fixing those bugs, if they are bugs, is not the job of the compiler.
> It's the job of the programmer, who is the one that knows what the
> code was supposed to do.  If there's a significant risk that the code
> is a mistake or might behave in problematic ways, a warning to that
> effect is more than enough.

Are you seriously saying that no accepts-invalid bug should ever be 
fixed under any circumstances on the basis that some programmers might 
rely on code exploiting that bug ??


>> C99 for the above says:
> I know what the standard says, but since when do we in the GNU project
> accept standards as a dictate?  We do what we consider to be best for
> our users, and follow the standards when that doesn't contradict what
> we think is best for the users.  GCC has, for example, -std=gnu99
> etc. precisely for that purpose.
>
>> The proposal is essentially to stop accepting this as a GNU extension
>> which was added for K&R compatibility I assume and do that only for C99 and
>> later.
> I understand.  I'm saying that there's no reason to make this an
> error, because it will break builds that have good reasons for keeping
> such code.
>
>> Note, this isn't valid even in C89 and is already rejected with
>> -pedantic-errors for years.
> Terrific!  Rejecting such code given a non-default option is _exactly_
> what should be done.  But we here are discussing the default behavior.
>
>>> It compiles today with a warning, so that whoever is interested to fix
>>> the code, can do that already.  The issue at hand is not whether to
>>> flag the code as highly suspicious, the issue at hand is whether
>>> upgrade the warning to errors.  So let's talk about the issue at hand,
>>> not about something else, okay?
>> We do such changes several times a year, where we reject something that has
>> been previously accepted in older standards, admittedly mostly in C++.
> And that is a Good Thing?  I don't think so.  Maybe for C++ it's
> inevitable, I'm not an expert on that.  But making breaking changes is
> inherently BAD and should be avoided.
>
>> Yes, it is done far less in C, but still, as the above is invalid already in
>> C89, users had over 3 decades to fix their code, and in many cases they
>> didn't and without this move they will never bother.
> Please consider those cases where the code cannot be "fixed", in
> practice.  I described one such situation in a previous message.
>
>> A lot of such broken code has been even written in those 3 decades, doesn't
>> predate it, but because the compiler just warned on it, it still appeared in
>> the code bases.  If we wait with this change another 2 decades, nothing will
>> change and we'll have the same problem then.
> GCC is not responsible for the existence of that code.  So GCC
> shouldn't change its decades-long behavior just because that code is
> there.  there must be a much more serious reason for such changes,
> something that affects GCC itself.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 08:10:48 -0400
> Cc: sam@gentoo.org, egall@gwmail.gwu.edu, jwakely.gcc@gmail.com, 
> 	joel@rtems.org, dje.gcc@gmail.com, jakub@redhat.com, arsen@aarsen.me, 
> 	gcc@gcc.gnu.org, c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Neal Gompa <neal@gompa.dev>
> > > Date: Wed, 10 May 2023 06:56:32 -0400
> > > Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org,
> > >       David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
> > >       Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org,
> > >       c-std-porting@lists.linux.dev
> > >
> > > Right, we've been going through a similar effort with C++ over the
> > > past decade. GCC incrementally becoming more strict on C++ has been an
> > > incredibly painful experience, and it eats away a ton of time that I
> > > would have spent dealing with other problems. Having one big event
> > > where the majority of changes to make the C compiler strict happen
> > > will honestly make it less painful, even if it doesn't seem like it at
> > > the moment.
> >
> > But not having such an event, ever, would be even less painful.
> 
> That's not going to happen.

Well, I hope it will.  Otherwise I wouldn't be partaking in this
discussion.

Re: More C type errors by default for GCC 14

[Sam James]

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


Eli Zaretskii via Gcc <gcc@gcc.gnu.org> writes:

>> From: Eric Gallager <egall@gwmail.gwu.edu>
>> Date: Wed, 10 May 2023 06:40:54 -0400
>> Cc: joel@rtems.org, David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
>> 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>, 
>> 	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
>> 
>> Idea for a compromise: What if, instead of flipping the switch on all
>> 3 of these at once, we staggered them so that each one becomes a
>> default in a separate release? i.e., something like:
>> 
>> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
>> - GCC 15: -Werror=implicit-int gets added to the defaults
>> - GCC 16: -Werror=int-conversion gets added to the defaults
>> 
>> That would give people more time to catch up on a particular warning,
>> rather than overwhelming them with a whole bunch all at once. Just an
>> idea.
>
> What do we tell those who cannot possibly "catch up", for whatever
> valid reasons?  E.g., consider a program written many years ago, which
> is safety-critical, and where making any changes requires so many
> validations and verifications that it is simply impractical, and will
> never be done.  Why would we want to break such programs?

Upgrading the toolchain is a change which requires validation, surely.

They can then test it at the same time as porting to modern C. Or simply
set the required options (as we're discussing) to allow older,
to-be-rejected constructs.

(It's also not clear to me that they're entitled to a GCC which always
works for them forever. People who like the behaviour of older GCCs
and refuse to change anything about their environment (not necessarily
their code) are able to stick with old versions if they wish.)

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

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Wed, 10 May 2023 13:30:10 +0100
> Cc: arsen@aarsen.me, dje.gcc@gmail.com, jakub@redhat.com, gcc@gcc.gnu.org
> 
> People are still using C to write new programs, and they are still
> making avoidable mistakes. The default for new code using new -std
> modes should be safer and less error prone.

I agree.  I just think that a warning strikes the right balance
between the two extremes.  And it is a balance, because once upon a
time, GCC didn't even warn about such code.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Sam James <sam@gentoo.org>
> Cc: David Brown <david@westcontrol.com>, gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 13:32:08 +0100
> 
> > I'm okay with making it harder, but without making it too hard for
> > those whose reasons for not changing the code are perfectly valid.
> > This proposal crosses that line, IMNSHO.
> 
> Could you give an example of how to make it harder without crossing
> the line for you?

Not really: I'm not involved enough in GCC development to be able to
provide such concrete examples off the top of my head.  I could think
about something like making it harder to disable the warnings about
such code, for example?

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 14:22, Eli Zaretskii via Gcc wrote:
>> From: Jonathan Wakely <jwakely.gcc@gmail.com>
>> Date: Wed, 10 May 2023 12:49:52 +0100
>> Cc: David Brown <david@westcontrol.com>, gcc@gcc.gnu.org
>>
>>> If some developers want to ignore warnings, it is not the business of
>>> GCC to improve them, even if you are right in assuming that they will
>>> not work around errors like they work around warnings (and I'm not at
>>> all sure you are right in that assumption).  But by _forcing_ these
>>> errors on _everyone_, GCC will in effect punish those developers who
>>> have good reasons for not changing the code.

What would those "good reasons" be, in your opinion?  (I realise I am 
asking you to be speculative and generalise.  This discussion is an 
exchange of opinions, thoughts, experiences and impressions.)

Frankly, the most common "good" reason for a developer not changing 
their code from pre-C99 is that they retired long ago.  And people 
should definitely question whether the code should be kept.

As I noted in another post, it is entirely reasonable to suspect that 
such old code has errors - unwarranted assumptions that were considered 
appropriate back in the days when such code techniques were considered 
appropriate.  It has always been the unfortunate case with C programming 
that getting optimal results for some compilers has sometimes involved 
"cheating" a bit, such as assuming wrapping signed arithmetic or 
converting pointer types and breaking the "strict aliasing" rules.

Changing the gcc defaults and requiring old code to use flags that allow 
old constructs but limiting optimisations is not /punishing/ the old 
code or its developers or maintainers.  It is /supporting/ it - allowing 
it to be used more safely with modern tools.


On the other hand, continuing to accept old, outdated code by lax 
defaults is punishing /current/ developers and users.  Why should 99.99% 
of current developers have to enable extra errors to catch mistakes (and 
we all make occasional mistakes in our coding - so they /should/ be 
enabling these error flags)?  Why should they have to deal with other 
people's code that was badly written 30 years ago?  Is it really worth 
it, just so that a half-dozen maintainers at Linux distributions can 
recompile the 40-year old source for "ed" without adding a flag to the 
makefile?


Ultimately, /someone/ is going to suffer - a compiler can't have good 
defaults for current developers and simultaneously good defaults for 
ancient relics.  The question to consider is not whether we "punish" 
someone, but /whom/ do we punish, and what is the best balance overall 
going forward.


>>
>> There will be options you can use to continue compiling the code
>> without changing it. You haven't given a good reason why it's OK for
>> one group of developers to have to use options to get their desired
>> behaviour from GCC, but completely unacceptable for a different group
>> to have to use options to get their desired behaviour.
>>
>> This is just a change in defaults.
> 
> A change in defaults that is not backward-compatible should only be
> done for very good reasons, because it breaks something that was
> working for years.  No such good reasons were provided.  

I'm sorry, but I believe I /did/ provide good reasons.  Granted, they 
were in more than one post.  And many others here have also given many 
good reasons.  At the very least, making a safer and more useful 
compiler that helps developers make better code is a good reason, as is 
making a C compiler that is closer to standards compatibility by default.

I do agree that backwards compatibility breaks should only be done for 
good reasons.  But I think the reasons are good.


> And no,
> educating/forcing GCC users to use more modern dialect of C is not a
> good reason.
> 

Yes, it /is/ a good reason.  But I suppose that one is a matter of opinion.

I encourage you to look at CERT/CC, or other lists of code errors 
leading to security issues or functional failures.  When someone writes 
poor code, lots of people suffer.  Any initiative that reduces the 
likelihood of such errors getting into the wild is not just good for gcc 
and its users, it's good for the whole society.

Consider why Rust has become the modern fad in programming.  People 
claim it is because it is inherently safer than C and C++.  It is not. 
There are really two reasons for it appearing to be safer.  One is that 
the /defaults/ for the tools, and the language idioms, are safer than 
the /defaults/ for C and C++ tools.  That makes it harder to make 
mistakes.  The other is that it has no legacy of decades of old code and 
old habits, and no newbie programmers copying those old styles.  Rust 
code is written in modern development styles, with a care for 
correctness rather than getting maximum efficiency from limited 
old-fashioned tools or macho programming.  The only reason there is any 
sense in re-writing old programs in Rust is because re-writing them in 
good, clear, modern C (or C++) is never going to happen - even though 
the results would be as safe or safer.

So yes, anything that pushes C programmers into being better C 
programmers is worth considering, IMHO.  We will never stamp out bad 
programming, but we can try to help them - giving them better tools that 
help them spot problems early is a step forward.


>> Accepting broken code by default is not a priori a good thing, as
>> you seem to insist. Rejecting it by default is not a priori a good
>> thing. There is a pragmatic choice to be made, and your argument is
>> still no more than "it compiles today, so it should compile
>> tomorrow".
> 
> Once again: it isn't "broken code".  It is dangerous code, and in some
> cases unintentionally suspicious code.  But it isn't broken, because
> GCC can compile it into a valid program, which, if the programmer
> indeed meant that, will work and do its job.
> 

Sweeping problems under the carpet and hoping no one trips over the 
bumps is, at best, pushing problems down the road for future developers.

Remember, when people wrote that old code, they didn't know the future 
of C, of compilers, of computers.  Maybe the code was not broken at the 
time, but times have changed.


>>>> Agreed.  But if we can make it harder for them to release bad code,
>>>> that's good overall.
>>>
>>> I'm okay with making it harder, but without making it too hard for
>>> those whose reasons for not changing the code are perfectly valid.
>>> This proposal crosses that line, IMNSHO.
>>
>> Where "too hard" means using a compiler option. Seriously? This seems farcical.
> 
> This goes both ways, of course.  GCC had -Werror since about forever.
> 

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Thomas Koenig via Gcc:

> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.

Thank you for sharing the Fortran perspective.  I think the C changes
are a bit different.  Most of these fixes are of a localized nature, and
there is always an ugly escape hatch for missing function declarations
(write a prototype declaration right next to the call site).  Most
packages we fixed required a small number of changes, and where
maintainers reacted, they weren't opposed to making the changes (maybe
with one exception).  These changes do not create an ongoing maintenance
burden.

Admittedly, there are some packages where the sheer number of issues
makes patchings things up difficult, or the state (and presumed lack of
use) of a program may make creating patches look like a waste of time.
But in the Fedora corpus, these cases are quite rare.  Popular packages
for which we do not have a migration story yet are ksh, procmail, unzip,
zip.  For the latter three, part of the problem is that it's not clear
to what extent legacy systems (pre-C89, maybe even pre-K&R, without
<stdlib.h> or <stddef.h>) still need to be supported.  These cases are
the exception, though.  In those cases, there could be a strong
incentive to make as few changes as possible (so telling the compiler to
keep accepting these obsolete constructs).

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 14:41:27 +0200
> Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org,
>  arsen@aarsen.me
> From: Gabriel Ravier <gabravier@gmail.com>
> 
> >>> Because GCC is capable of compiling it.
> >> That is not a good argument.  GCC is capable of compiling any code in all
> >> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> >> mean those bugs shouldn't be fixed.
> > Fixing those bugs, if they are bugs, is not the job of the compiler.
> > It's the job of the programmer, who is the one that knows what the
> > code was supposed to do.  If there's a significant risk that the code
> > is a mistake or might behave in problematic ways, a warning to that
> > effect is more than enough.
> 
> Are you seriously saying that no accepts-invalid bug should ever be 
> fixed under any circumstances on the basis that some programmers might 
> rely on code exploiting that bug ??

Sorry, I'm afraid I don't understand the question.  What are
"accepts-invalid bugs"?

In any case, I was not not talking about bug-compatibility, I was
talking about being able to compile code which GCC was able to compile
in past versions.  Being able to compile that code is not a bug, it's
a feature.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Wed, May 10, 2023 at 05:14:43PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 14:41:27 +0200
> > Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org,
> >  arsen@aarsen.me
> > From: Gabriel Ravier <gabravier@gmail.com>
> > 
> > >>> Because GCC is capable of compiling it.
> > >> That is not a good argument.  GCC is capable of compiling any code in all
> > >> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> > >> mean those bugs shouldn't be fixed.
> > > Fixing those bugs, if they are bugs, is not the job of the compiler.
> > > It's the job of the programmer, who is the one that knows what the
> > > code was supposed to do.  If there's a significant risk that the code
> > > is a mistake or might behave in problematic ways, a warning to that
> > > effect is more than enough.
> > 
> > Are you seriously saying that no accepts-invalid bug should ever be 
> > fixed under any circumstances on the basis that some programmers might 
> > rely on code exploiting that bug ??
> 
> Sorry, I'm afraid I don't understand the question.  What are
> "accepts-invalid bugs"?

They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c&keywords=accepts-invalid&keywords_type=allwords&list_id=382024&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
82 such bugs in C++:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c%2B%2B&keywords=accepts-invalid&keywords_type=allwords&list_id=382025&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
and a couple in other languages.

E.g. today I've committed a C++ FE fix, where we erroneously accepted
e.g.
template <int ...args>
[[noreturn...]]
int foo ();
and handled it as if the ... after the attribute wasn't present.
In this case also you were able to compile such code in the past GCC
versions and it will not compile in G++ 14.1 anymore.

What we are talking in this thread is also something not valid in C99 or
later, for the int-conversion stuff not even valid in C89, in the past
accepted just for K&R legacy reasons.

	Jakub

Re: More C type errors by default for GCC 14

[Thomas Koenig]

On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
> We do such changes several times a year, where we reject something that has
> been previously accepted in older standards, admittedly mostly in C++.

... and in Fortran.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 15:30:02 +0200
> From: David Brown via Gcc <gcc@gcc.gnu.org>
> 
> >>> If some developers want to ignore warnings, it is not the business of
> >>> GCC to improve them, even if you are right in assuming that they will
> >>> not work around errors like they work around warnings (and I'm not at
> >>> all sure you are right in that assumption).  But by _forcing_ these
> >>> errors on _everyone_, GCC will in effect punish those developers who
> >>> have good reasons for not changing the code.
> 
> What would those "good reasons" be, in your opinion?

For example, something that adversely affects GCC itself and its
ability to compile valid programs.

> On the other hand, continuing to accept old, outdated code by lax 
> defaults is punishing /current/ developers and users.  Why should 99.99% 
> of current developers have to enable extra errors to catch mistakes (and 
> we all make occasional mistakes in our coding - so they /should/ be 
> enabling these error flags)?

Adding a flag to a Makefile is infinitely easier than fixing old
sources in a way that they produce the same machine code.

> I do agree that backwards compatibility breaks should only be done for 
> good reasons.  But I think the reasons are good.

Not good enough, not for such a radical shift in the balance between
the two groups.

> > And no,
> > educating/forcing GCC users to use more modern dialect of C is not a
> > good reason.
> > 
> 
> Yes, it /is/ a good reason.

Not for a compiler.  A compiler is a tool, it is none of its business
to teach me what is and what isn't a good dialect in each particular
case.  Hinting on that, via warnings, is sufficient and perfectly
okay, but _forcing_ me is not.

> Consider why Rust has become the modern fad in programming.  People 
> claim it is because it is inherently safer than C and C++.  It is not. 
> There are really two reasons for it appearing to be safer.  One is that 
> the /defaults/ for the tools, and the language idioms, are safer than 
> the /defaults/ for C and C++ tools.  That makes it harder to make 
> mistakes.  The other is that it has no legacy of decades of old code and 
> old habits, and no newbie programmers copying those old styles.

Exactly.  We cannot reasonably expect that a compiler which needs to
support 50 years of legacy code to be as safe as a compiler for a
language invented yesterday afternoon.  People who want a safe
programming environment should not choose C as their first choice.

> So yes, anything that pushes C programmers into being better C 
> programmers is worth considering, IMHO.  We will never stamp out bad 
> programming, but we can try to help them - giving them better tools that 
> help them spot problems early is a step forward.

I agree, I'm just saying that warnings are helpful enough -- for those
who want to be helped.

> > Once again: it isn't "broken code".  It is dangerous code, and in some
> > cases unintentionally suspicious code.  But it isn't broken, because
> > GCC can compile it into a valid program, which, if the programmer
> > indeed meant that, will work and do its job.
> 
> Sweeping problems under the carpet and hoping no one trips over the 
> bumps is, at best, pushing problems down the road for future developers.

I'm not sweeping anything.  This is not GCC's problem to solve, that's
all.  If the developer avoids dealing with this problem, then he or
she might be sweeping the problem under the carpet.  But this is not
GCC's problem.

Re: More C type errors by default for GCC 14

[Joel Sherrill]

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

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

> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > We are currently using gcc 12 and specifying C11.  To experiment with
> > these stricter warnings and slowly address them, would we need to build
> > with a newer C version?
>
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!
>
>
> > What practices might the GCC community recommend to a project
> > wanting to discover the issues uncovered and slowly address them? I
>
> -Werror=implicit-int
> -Werror=implicit-function-declaration
> -Werror=int-conversion
>

Thanks. We already  use -Wall which is documented to turn on the top two
as warnings at least.

Is int-conversion turned on as part of any of the more general -W arguments
(e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
wondering
if that was right or an oversight. Given this discussion, I would have
expected it
to be in -Wall.

--joel


> > i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
> > where the improved strict alias checking gave us a LOT of warnings to
> > deal with and it felt overwhelming. I don't want to do that again.
> >
> > But I believe in letting the compiler get stricter and find things.
> Defaulting
> > to stricter checking is a good thing.
>
> The checks are already done, they're just warnings by default, and so
> easily missed/ignored when compiling large code bases.
>

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > What practices might the GCC community recommend to a project
> > > wanting to discover the issues uncovered and slowly address them? I
> >
> > -Werror=implicit-int
> > -Werror=implicit-function-declaration
> > -Werror=int-conversion
> >
> 
> Thanks. We already  use -Wall which is documented to turn on the top two
> as warnings at least.
> 
> Is int-conversion turned on as part of any of the more general -W arguments
> (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> wondering
> if that was right or an oversight. Given this discussion, I would have
> expected it
> to be in -Wall.

-Wint-conversion is enabled by default.  You get the warning whenever not
using -w or -Wno-int-conversion, and error with -pedantic-errors.

	Jakub

Re: More C type errors by default for GCC 14

[Paul Koning]

> On May 10, 2023, at 10:39 AM, Eli Zaretskii via Gcc <gcc@gcc.gnu.org> wrote:
> 
>> ...
>> Sweeping problems under the carpet and hoping no one trips over the 
>> bumps is, at best, pushing problems down the road for future developers.
> 
> I'm not sweeping anything.  This is not GCC's problem to solve, that's
> all.  If the developer avoids dealing with this problem, then he or
> she might be sweeping the problem under the carpet.  But this is not
> GCC's problem.

Agreed.  -Wall -Werror exists for a reason, and choosing to use that it helpful but not necessarily feasible for everyone if confronted with old mouldy code.

I remember a wonderful article (out of MIT?) explaining a whole bunch of somewhat-surprising C standard rules and why they allowed the compiler to do things that many people don't expect.  As I recall, a lot of those were things that Linux didn't want and therefore would suppress with suitable -f<mumble> flags.  "Strict aliasing" may have been one of those -- I still remember my somewhat-surprised reaction when I first learned what that is and why my "obvious" C code was not valid.

I also agree with Eli that using C to write highly reliable code is, shall we say, quite a challenge.  The language just isn't well suited for that.  But GCC also supports Ada.... :-)  and now Modula-2.

	paul

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 16:22:26 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Gabriel Ravier <gabravier@gmail.com>, jwakely.gcc@gmail.com,
>         fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me
> 
> > > Are you seriously saying that no accepts-invalid bug should ever be 
> > > fixed under any circumstances on the basis that some programmers might 
> > > rely on code exploiting that bug ??
> > 
> > Sorry, I'm afraid I don't understand the question.  What are
> > "accepts-invalid bugs"?
> 
> They are bugs where compiler accepts something that isn't valid in
> the selected language nor considered valid extension.
> So, after the fix we reject something that has been accepted before.

If some program is plainly invalid, not just because the criteria of
validity have shifted, then yes, such a program should be rejected.

> What we are talking in this thread is also something not valid in C99 or
> later, for the int-conversion stuff not even valid in C89, in the past
> accepted just for K&R legacy reasons.

Yes, and that's the crucial (for me) difference: what is currently
considered invalid was valid in the past, and so there's a set of
rules under which that kind of program can produce valid machine code.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 16:31:23 +0200
> From: Thomas Koenig via Gcc <gcc@gcc.gnu.org>
> 
> On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
> > We do such changes several times a year, where we reject something that has
> > been previously accepted in older standards, admittedly mostly in C++.
> 
> ... and in Fortran.

Tell me about it.  Just a couple of months ago I needed to compile the
venerable Adventure game from 1977 sources (for my grandson).  That
was no fun, although there was, of course, nothing wrong with the
source code, and once I tweaked gfortran into accepting that flavor of
Fortran, it compiled and ran just fine.

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 16:14, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 14:41:27 +0200
>> Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org,
>>   arsen@aarsen.me
>> From: Gabriel Ravier <gabravier@gmail.com>
>>
>>>>> Because GCC is capable of compiling it.
>>>> That is not a good argument.  GCC is capable of compiling any code in all
>>>> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
>>>> mean those bugs shouldn't be fixed.
>>> Fixing those bugs, if they are bugs, is not the job of the compiler.
>>> It's the job of the programmer, who is the one that knows what the
>>> code was supposed to do.  If there's a significant risk that the code
>>> is a mistake or might behave in problematic ways, a warning to that
>>> effect is more than enough.
>>
>> Are you seriously saying that no accepts-invalid bug should ever be
>> fixed under any circumstances on the basis that some programmers might
>> rely on code exploiting that bug ??
> 
> Sorry, I'm afraid I don't understand the question.  What are
> "accepts-invalid bugs"?
> 

They are cases where the C standards (plus documented gcc extensions) 
have syntax or constraint requirements, but code which breaks these 
requirements is accepted by the compiler.  For example, if the compiler 
accepted "long long long int" as a type, that would be an 
"accepts-invalid" bug.  They are important for two reasons.  One is that 
they mean the compiler fails to help the developer catch the mistake in 
their code.  The other is that the code might have an inconsistent 
interpretation, and that might change in the future.  In the 
hypothetical example of a three-long int, a current compiler might treat 
it as a "long long", while a future standard might add support for it as 
a new type with minimum 128-bit size.

> In any case, I was not not talking about bug-compatibility, I was
> talking about being able to compile code which GCC was able to compile
> in past versions.  Being able to compile that code is not a bug, it's
> a feature.
> 

No, being able to compile /incorrect/ code by default is a bug.  It is 
not helpful.

(The compiler cannot, of course, spot /all/ mistakes - the gcc 
developers are a smart group, but I think asking them to solve the 
Halting Problem is a bit much!)

I've seen this kind of argument many times - "The compiler used to 
accept my code and give the results I wanted, and now newer compiler 
versions make a mess of it".  The cause is almost invariably undefined 
behaviour, but it can occasionally be through changes to the standards 
such as removal of old behaviour or other differences in the 
interpretation of code (there were a number of incompatibilities between 
K&R and C90, and between C90 and C99).

The compiler is under /no/ obligation to compile undefined behaviour in 
the same way as it might have done for a particular piece of code.  It 
is under /no/ obligation to continue to accept incorrect or invalid 
code, just because it used to accept it.  It /is/ - IMHO - under an 
obligation to do what it can to help spot problems in code and help 
developers get good quality correct code in the end.  If it fails to do 
that, people will, and should, move to using different tools.

New compiler versions are not required to do two's complement wrapping 
of signed integer overflow, even though old broken code might have been 
written under the assumption that it did and even though older, less 
powerful versions of the compiler might have compiled that code into 
something the developer wanted.  In the same way, new compiler versions 
are not required to support syntax that has been dead for decades - at 
least not by default.  (Unlike most other compilers, gcc developers go 
far out of their way to support such outdated and incorrect code - all 
they ask is that people use non-default flags to get such non-standard 
syntax and semantics.)

If the gcc developers really were required to continue to compile /all/ 
programs that compiled before, with the same results, then the whole gcc 
project can be stopped.  The only way to ensure perfect backwards 
compatibility would be to stop development, and no longer release any 
new versions of the compiler.  That is the logical consequence of "it 
used to compile (with defaults or a given set of flags), so it should 
continue to compile (with these same flags)" - assuming "compile" here 
means "giving the same resulting behaviour in the executable" rather 
than just "giving an executable that may or may not work".

Clearly, you don't mean gcc development should stop.  That means a line 
must be drawn, and some code that compiled with older gcc will not 
compile with newer gcc.  The only question is where the line should be.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Wed, May 10, 2023 at 06:30:40PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 16:22:26 +0200
> > From: Jakub Jelinek <jakub@redhat.com>
> > Cc: Gabriel Ravier <gabravier@gmail.com>, jwakely.gcc@gmail.com,
> >         fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me
> > 
> > > > Are you seriously saying that no accepts-invalid bug should ever be 
> > > > fixed under any circumstances on the basis that some programmers might 
> > > > rely on code exploiting that bug ??
> > > 
> > > Sorry, I'm afraid I don't understand the question.  What are
> > > "accepts-invalid bugs"?
> > 
> > They are bugs where compiler accepts something that isn't valid in
> > the selected language nor considered valid extension.
> > So, after the fix we reject something that has been accepted before.
> 
> If some program is plainly invalid, not just because the criteria of
> validity have shifted, then yes, such a program should be rejected.

Many of the accepts-invalid cases are when something used to be valid in some
older standard and is not valid in a newer standard, often even changes
meaning completely in even newer standard.
Examples include e.g. the auto keyword, which means something completely
different in C++11 and later than what it meant in C++98, or say comma in
array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
in C++17, got deprecated in C++20 and is ill-formed or changed meaning
in C++23 (multi-dimensional array operator).
Or any time something that wasn't a keyword in older standard version
and is a keyword in a newer standard.
alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
char16_t/char32_t/constexpr/decltype/noexcept in C++11,
constinit/consteval in C++20,
bool/false/true/typeof_unqual in C23.

int bool = 1;
is completely valid C17 if one doesn't include <stdbool.h> header,
or
int static_assert = 2;
valid C17 if one doesn't include <assert.h>
etc.  These used to compile and will no any longer wheen using -std=c2x or
in a few years when -std=gnu23 becomes the default will not compile by
default, even when it used to be valid C17.
And here are talking about code that wasn't valid already in C99...

	Jakub

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 16:39, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 15:30:02 +0200
>> From: David Brown via Gcc <gcc@gcc.gnu.org>
>>
>>>>> If some developers want to ignore warnings, it is not the business of
>>>>> GCC to improve them, even if you are right in assuming that they will
>>>>> not work around errors like they work around warnings (and I'm not at
>>>>> all sure you are right in that assumption).  But by _forcing_ these
>>>>> errors on _everyone_, GCC will in effect punish those developers who
>>>>> have good reasons for not changing the code.
>>
>> What would those "good reasons" be, in your opinion?
> 
> For example, something that adversely affects GCC itself and its
> ability to compile valid programs.

If gcc itself contains code that relies on outdated features, these 
should be fixed in the gcc source code.  It is one thing to suggest that 
a project that has been "maintenance only" for several decades cannot 
reasonably be updated, but that does not apply to current programs like gcc.

> 
>> On the other hand, continuing to accept old, outdated code by lax
>> defaults is punishing /current/ developers and users.  Why should 99.99%
>> of current developers have to enable extra errors to catch mistakes (and
>> we all make occasional mistakes in our coding - so they /should/ be
>> enabling these error flags)?
> 
> Adding a flag to a Makefile is infinitely easier than fixing old
> sources in a way that they produce the same machine code.
> 

The suggestion has been - always - that support for old syntaxes be 
retained.  But that flag should be added to the makefiles of the 0.01% 
of projects that need it because they have old code - not the 99.99% of 
projects that are written (or updated) this century.

>> I do agree that backwards compatibility breaks should only be done for
>> good reasons.  But I think the reasons are good.
> 
> Not good enough, not for such a radical shift in the balance between
> the two groups.
> 

Do you have any reason to believe that the old code group is of relevant 
size?  I think it is quite obvious that I have been pulling percentages 
out of thin air, but can you justify claiming anything different?

I mean, if gcc simply added a default "-Werror=implicit" flag in the 
release candidate for gcc-14, how many people do you think would 
actually complain?  I'd guess that there would be far fewer complaints 
than there are posts in this thread discussing whether or not it's a 
good idea.


>>> And no,
>>> educating/forcing GCC users to use more modern dialect of C is not a
>>> good reason.
>>>
>>
>> Yes, it /is/ a good reason.
> 
> Not for a compiler.  A compiler is a tool, it is none of its business
> to teach me what is and what isn't a good dialect in each particular
> case.  Hinting on that, via warnings, is sufficient and perfectly
> okay, but _forcing_ me is not.

Again - did you miss the point about people who really want to work with 
old code can do so, by picking the right flag(s) ?

> 
>> Consider why Rust has become the modern fad in programming.  People
>> claim it is because it is inherently safer than C and C++.  It is not.
>> There are really two reasons for it appearing to be safer.  One is that
>> the /defaults/ for the tools, and the language idioms, are safer than
>> the /defaults/ for C and C++ tools.  That makes it harder to make
>> mistakes.  The other is that it has no legacy of decades of old code and
>> old habits, and no newbie programmers copying those old styles.
> 
> Exactly.  We cannot reasonably expect that a compiler which needs to
> support 50 years of legacy code to be as safe as a compiler for a
> language invented yesterday afternoon.  People who want a safe
> programming environment should not choose C as their first choice.
> 

We cannot expect a /language/ with a 50 year history to be as safe as a 
modern one.  But we can expect a /compiler/ released /today/ to be as 
safe as it can be made /today/.

I agree that C is not the best choice of language for many people. 
Actually, I'd say that most people who program in C would be better off 
programming in something else.  And most programs that are written in C 
could be better in a different language.  But when C /is/ the right 
choice - or even when it is the choice made despite being the wrong 
choice, I want it to be /good/ C, and I want tools to help out there as 
best they possibly can.  That includes good default flags, because not 
all gcc users are experts on gcc flags.

My ideal, actually, would be that gcc has "-Wall -Wextra" by default, 
trying to help developers from the get-go.  It should also have an flag 
"-sep" that disables all warnings and uses lax modes, for people using 
it to build software provided by others and they want nothing to do with 
the source code.  But of course that is not the ideal situation for 
everyone else!

(See <https://en.wikipedia.org/wiki/Somebody_else%27s_problem> for an 
explanation behind the "-sep" flag.)


>> So yes, anything that pushes C programmers into being better C
>> programmers is worth considering, IMHO.  We will never stamp out bad
>> programming, but we can try to help them - giving them better tools that
>> help them spot problems early is a step forward.
> 
> I agree, I'm just saying that warnings are helpful enough -- for those
> who want to be helped.
> 
>>> Once again: it isn't "broken code".  It is dangerous code, and in some
>>> cases unintentionally suspicious code.  But it isn't broken, because
>>> GCC can compile it into a valid program, which, if the programmer
>>> indeed meant that, will work and do its job.
>>
>> Sweeping problems under the carpet and hoping no one trips over the
>> bumps is, at best, pushing problems down the road for future developers.
> 
> I'm not sweeping anything.  This is not GCC's problem to solve, that's
> all.  If the developer avoids dealing with this problem, then he or
> she might be sweeping the problem under the carpet.  But this is not
> GCC's problem.
> 

GCC currently provides the brush and the carpet lifter as standard 
equipment.  All we are suggesting is that these are not provided by 
default, and require extra effort to access.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 17:58:16 +0200
> From: David Brown via Gcc <gcc@gcc.gnu.org>
> 
> > In any case, I was not not talking about bug-compatibility, I was
> > talking about being able to compile code which GCC was able to compile
> > in past versions.  Being able to compile that code is not a bug, it's
> > a feature.
> 
> No, being able to compile /incorrect/ code by default is a bug.  It is 
> not helpful.

I actually agree; we just have different definitions of "incorrect".

> I've seen this kind of argument many times - "The compiler used to 
> accept my code and give the results I wanted, and now newer compiler 
> versions make a mess of it".

But we are not talking about some random code that just happened to
slip through cracks as a side effect of the particular implementation.
We are talking about code that was perfectly valid, had well-defined
semantics, and produced a working program.  I don't care about the
former; I do care about the latter.

> If the gcc developers really were required to continue to compile /all/ 
> programs that compiled before, with the same results, then the whole gcc 
> project can be stopped.

You will have to explain this to me.  Just stating this is not enough.
How will accepting K&R stop GCC development?

As for the two's complement wrapping example: I'm okay with having
this broken because some useful feature requires to modify the basic
arithmetics and instructions emitted by GCC in a way that two's
complement wrapping can no longer be supported.  _That_ is exactly an
example of a "good reason" for backward incompatibility: GCC must do
something to compile valid programs, and that something is
incompatible with old programs which depended on some de-facto
standard that is nowadays considered UB.  But the case in point is not
like that, AFAIU: in this case, GCC will deliberately break a program
although it could compile it without adversely affecting its output
for any other valid program.  To me, this would be an arbitrary
decision of the GCC developers to break someone's code that has no
"good reasons" which I could understand and respect, let alone accept.

> The only way to ensure perfect backwards compatibility would be to
> stop development, and no longer release any new versions of the
> compiler.  That is the logical consequence of "it used to compile
> (with defaults or a given set of flags), so it should continue to
> compile (with these same flags)" - assuming "compile" here means
> "giving the same resulting behaviour in the executable" rather than
> just "giving an executable that may or may not work".

This is not the logical consequence, this is reductio ad absurdum, a
kind of strawman.  There's no need to go to such extremes, because
"good reasons" for breaking backward compatibility do exist.  I'm a
co-maintainer of GNU Emacs, a program that attempts not to break
habits of users burned into their muscle memories for the last 30
years; don't you think I know a bit what I'm talking about?

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 18:02:53 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com,
>         gcc@gcc.gnu.org, arsen@aarsen.me
> 
> > If some program is plainly invalid, not just because the criteria of
> > validity have shifted, then yes, such a program should be rejected.
> 
> Many of the accepts-invalid cases are when something used to be valid in some
> older standard and is not valid in a newer standard, often even changes
> meaning completely in even newer standard.
> Examples include e.g. the auto keyword, which means something completely
> different in C++11 and later than what it meant in C++98, or say comma in
> array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
> in C++17, got deprecated in C++20 and is ill-formed or changed meaning
> in C++23 (multi-dimensional array operator).
> Or any time something that wasn't a keyword in older standard version
> and is a keyword in a newer standard.
> alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
> char16_t/char32_t/constexpr/decltype/noexcept in C++11,
> constinit/consteval in C++20,
> bool/false/true/typeof_unqual in C23.
> 
> int bool = 1;
> is completely valid C17 if one doesn't include <stdbool.h> header,
> or
> int static_assert = 2;
> valid C17 if one doesn't include <assert.h>
> etc.  These used to compile and will no any longer wheen using -std=c2x or
> in a few years when -std=gnu23 becomes the default will not compile by
> default, even when it used to be valid C17.

The examples you gave are the ones I could accept as "good reasons"
for breaking backward compatibility.  That's because breaking that is
unavoidable if GCC wants to support the newer standard.

That is not the case we are discussing, AFAIU.  Or at least no one has
yet explained why accepting those old K&R programs will adversely
affect the ability of GCC to compile C2x programs.

Re: More C type errors by default for GCC 14

[Richard Biener]

> Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc <gcc@gcc.gnu.org>:
> 
> 
>> 
>> Date: Wed, 10 May 2023 18:02:53 +0200
>> From: Jakub Jelinek <jakub@redhat.com>
>> Cc: gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com,
>>        gcc@gcc.gnu.org, arsen@aarsen.me
>> 
>>> If some program is plainly invalid, not just because the criteria of
>>> validity have shifted, then yes, such a program should be rejected.
>> 
>> Many of the accepts-invalid cases are when something used to be valid in some
>> older standard and is not valid in a newer standard, often even changes
>> meaning completely in even newer standard.
>> Examples include e.g. the auto keyword, which means something completely
>> different in C++11 and later than what it meant in C++98, or say comma in
>> array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
>> in C++17, got deprecated in C++20 and is ill-formed or changed meaning
>> in C++23 (multi-dimensional array operator).
>> Or any time something that wasn't a keyword in older standard version
>> and is a keyword in a newer standard.
>> alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
>> char16_t/char32_t/constexpr/decltype/noexcept in C++11,
>> constinit/consteval in C++20,
>> bool/false/true/typeof_unqual in C23.
>> 
>> int bool = 1;
>> is completely valid C17 if one doesn't include <stdbool.h> header,
>> or
>> int static_assert = 2;
>> valid C17 if one doesn't include <assert.h>
>> etc.  These used to compile and will no any longer wheen using -std=c2x or
>> in a few years when -std=gnu23 becomes the default will not compile by
>> default, even when it used to be valid C17.
> 
> The examples you gave are the ones I could accept as "good reasons"
> for breaking backward compatibility.  That's because breaking that is
> unavoidable if GCC wants to support the newer standard.
> 
> That is not the case we are discussing, AFAIU.  Or at least no one has
> yet explained why accepting those old K&R programs will adversely
> affect the ability of GCC to compile C2x programs.

But we are discussing to reject K&R programs only when C99 or later standards are applied (those are applied by default)

Richard 

Re: More C type errors by default for GCC 14

[Joel Sherrill]

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

On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek <jakub@redhat.com> wrote:

> On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > What practices might the GCC community recommend to a project
> > > > wanting to discover the issues uncovered and slowly address them? I
> > >
> > > -Werror=implicit-int
> > > -Werror=implicit-function-declaration
> > > -Werror=int-conversion
> > >
> >
> > Thanks. We already  use -Wall which is documented to turn on the top two
> > as warnings at least.
> >
> > Is int-conversion turned on as part of any of the more general -W
> arguments
> > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> > wondering
> > if that was right or an oversight. Given this discussion, I would have
> > expected it
> > to be in -Wall.
>
> -Wint-conversion is enabled by default.  You get the warning whenever not
> using -w or -Wno-int-conversion, and error with -pedantic-errors.
>

Thanks. That isn't clear in the manual.

Is there a list of warnings included by default? I'm guessing that it might
be all the ones where the manual lists only -Wno-ABC.

And again, I don't mind getting poked when the code does something
questionable or undefined. Doesn't make it easy to fix or even magically
give us all time to address the issues but better to know.

--joel

>
>         Jakub
>
>

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Wed, May 10, 2023 at 11:36:10AM -0500, Joel Sherrill wrote:
> On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > > What practices might the GCC community recommend to a project
> > > > > wanting to discover the issues uncovered and slowly address them? I
> > > >
> > > > -Werror=implicit-int
> > > > -Werror=implicit-function-declaration
> > > > -Werror=int-conversion
> > > >
> > >
> > > Thanks. We already  use -Wall which is documented to turn on the top two
> > > as warnings at least.
> > >
> > > Is int-conversion turned on as part of any of the more general -W
> > arguments
> > > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> > > wondering
> > > if that was right or an oversight. Given this discussion, I would have
> > > expected it
> > > to be in -Wall.
> >
> > -Wint-conversion is enabled by default.  You get the warning whenever not
> > using -w or -Wno-int-conversion, and error with -pedantic-errors.
> >
> 
> Thanks. That isn't clear in the manual.
> 
> Is there a list of warnings included by default? I'm guessing that it might
> be all the ones where the manual lists only -Wno-ABC.
> 
> And again, I don't mind getting poked when the code does something
> questionable or undefined. Doesn't make it easy to fix or even magically
> give us all time to address the issues but better to know.

awk '/^W/{w=$1;getline;if ($0 ~ /Init\(1\)/)print w}' gcc/{,*/}*.opt | sort -u
Waddress-of-packed-member
Waggressive-loop-optimizations
Walign-commons
Wanalyzer-allocation-size
Wanalyzer-deref-before-check
Wanalyzer-double-fclose
Wanalyzer-double-free
Wanalyzer-exposure-through-output-file
Wanalyzer-exposure-through-uninit-copy
Wanalyzer-fd-access-mode-mismatch
Wanalyzer-fd-double-close
Wanalyzer-fd-leak
Wanalyzer-fd-phase-mismatch
Wanalyzer-fd-type-mismatch
Wanalyzer-fd-use-after-close
Wanalyzer-fd-use-without-check
Wanalyzer-file-leak
Wanalyzer-free-of-non-heap
Wanalyzer-imprecise-fp-arithmetic
Wanalyzer-infinite-recursion
Wanalyzer-jump-through-null
Wanalyzer-malloc-leak
Wanalyzer-mismatching-deallocation
Wanalyzer-null-argument
Wanalyzer-null-dereference
Wanalyzer-out-of-bounds
Wanalyzer-possible-null-argument
Wanalyzer-possible-null-dereference
Wanalyzer-putenv-of-auto-var
Wanalyzer-shift-count-negative
Wanalyzer-shift-count-overflow
Wanalyzer-stale-setjmp-buffer
Wanalyzer-tainted-allocation-size
Wanalyzer-tainted-array-index
Wanalyzer-tainted-assertion
Wanalyzer-tainted-divisor
Wanalyzer-tainted-offset
Wanalyzer-tainted-size
Wanalyzer-unsafe-call-within-signal-handler
Wanalyzer-use-after-free
Wanalyzer-use-of-pointer-in-stale-stack-frame
Wanalyzer-use-of-uninitialized-value
Wanalyzer-va-arg-type-mismatch
Wanalyzer-va-list-exhausted
Wanalyzer-va-list-leak
Wanalyzer-va-list-use-after-va-end
Wanalyzer-write-to-const
Wanalyzer-write-to-string-literal
Wattribute-alias=
Wattributes
Wattribute-warning
Wbuiltin-declaration-mismatch
Wbuiltin-macro-redefined
Wc++11-extensions
Wc++14-extensions
Wc++17-extensions
Wc++20-extensions
Wc++23-extensions
Wcannot-profile
Wchanges-meaning
Wclass-conversion
Wcomplain-wrong-lang
Wconversion-null
Wcoverage-invalid-line-number
Wcoverage-mismatch
Wcpp
Wdelete-incomplete
Wdeprecated
Wdeprecated-declarations
Wdesignated-init
Wdiscarded-array-qualifiers
Wdiscarded-qualifiers
Wdiv-by-zero
Wendif-labels
Wexceptions
Wfree-nonheap-object
Wif-not-aligned
Wignored-attributes
Winaccessible-base
Wincompatible-pointer-types
Winherited-variadic-ctor
Winit-list-lifetime
Wint-conversion
Winterference-size
Wint-to-pointer-cast
Winvalid-memory-model
Winvalid-offsetof
Wliteral-suffix
Wlto-type-mismatch
Wmissing-profile
Wmissing-requires
Wmissing-template-keyword
Wnonportable-cfstrings
Wnon-template-friend
WNSObject-attribute
Wobjc-root-class
Wodr
Woverflow
Woverride-init-side-effects
Woverwrite-recursive
Wpmf-conversions
Wpointer-compare
Wpointer-to-int-cast
Wpragmas
Wprio-ctor-dtor
Wproperty-assign-default
Wprotocol
Wpsabi
Wreturn-local-addr
Wscalar-storage-order
Wshadow-ivar
Wshift-count-negative
Wshift-count-overflow
Wsizeof-array-argument
Wstringop-overread
Wsubobject-linkage
Wswitch-bool
Wswitch-outside-range
Wswitch-unreachable
Wsync-nand
Wterminate
Wtsan
Wunderflow
Wunicode
Wunused-result
Wvarargs
Wvexing-parse
Wvirtual-move-assign
Wxor-used-as-pow

Of course, e.g. the -Wanalyzer* warnings are doing something only if
-fanalyzer, or say -Wtsan if -fsanitize=thread etc.

	Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 18:20:50 +0200
> From: David Brown via Gcc <gcc@gcc.gnu.org>
> 
> > Adding a flag to a Makefile is infinitely easier than fixing old
> > sources in a way that they produce the same machine code.
> 
> The suggestion has been - always - that support for old syntaxes be 
> retained.  But that flag should be added to the makefiles of the 0.01% 
> of projects that need it because they have old code - not the 99.99% of 
> projects that are written (or updated) this century.

Percents don't count when you are the one who is in trouble.

> > Exactly.  We cannot reasonably expect that a compiler which needs to
> > support 50 years of legacy code to be as safe as a compiler for a
> > language invented yesterday afternoon.  People who want a safe
> > programming environment should not choose C as their first choice.
> 
> We cannot expect a /language/ with a 50 year history to be as safe as a 
> modern one.  But we can expect a /compiler/ released /today/ to be as 
> safe as it can be made /today/.

Not if the compiler should support legacy code, we can't.

Anyway, we are repeating ourselves.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Richard Biener <richard.guenther@gmail.com>
> Date: Wed, 10 May 2023 18:33:53 +0200
> Cc: Jakub Jelinek <jakub@redhat.com>, gabravier@gmail.com,
>  jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me
> 
> 
> 
> > Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc <gcc@gcc.gnu.org>:
> > The examples you gave are the ones I could accept as "good reasons"
> > for breaking backward compatibility.  That's because breaking that is
> > unavoidable if GCC wants to support the newer standard.
> > 
> > That is not the case we are discussing, AFAIU.  Or at least no one has
> > yet explained why accepting those old K&R programs will adversely
> > affect the ability of GCC to compile C2x programs.
> 
> But we are discussing to reject K&R programs only when C99 or later standards are applied (those are applied by default)

I understand, but I don't see the relevance.  Are you saying that
"-std=c99" accepts _only_ C99 valid constructs?  What about gnu99?

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Wed, 10 May 2023 at 17:36, Joel Sherrill <joel@rtems.org> wrote:
>
>
>
> On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
>> > > > What practices might the GCC community recommend to a project
>> > > > wanting to discover the issues uncovered and slowly address them? I
>> > >
>> > > -Werror=implicit-int
>> > > -Werror=implicit-function-declaration
>> > > -Werror=int-conversion
>> > >
>> >
>> > Thanks. We already  use -Wall which is documented to turn on the top two
>> > as warnings at least.
>> >
>> > Is int-conversion turned on as part of any of the more general -W arguments
>> > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
>> > wondering
>> > if that was right or an oversight. Given this discussion, I would have
>> > expected it
>> > to be in -Wall.
>>
>> -Wint-conversion is enabled by default.  You get the warning whenever not
>> using -w or -Wno-int-conversion, and error with -pedantic-errors.
>
>
> Thanks. That isn't clear in the manual.

See https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html which says:

"Many options have long names starting with ‘-f’ or with ‘-W’—for
example, -fmove-loop-invariants, -Wformat and so on. Most of these
have both positive and negative forms; the negative form of -ffoo is
-fno-foo. This manual documents only one of these two forms, whichever
one is not the default. "

And the manual documents the -Wno-int-conversion form, because
-Wint-conversion is the default:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wno-int-conversion

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:

> That is not the case we are discussing, AFAIU.  Or at least no one has
> yet explained why accepting those old K&R programs will adversely
> affect the ability of GCC to compile C2x programs.

At block scope,

  auto x = 1.5;

declares x to have type double in C2x (C++-style auto), but type int in 
C89 (and is invalid for versions in between).  In this case, there is an 
incompatible semantic change between implicit int and C++-style auto.  
Giving an error before we make -std=gnu2x the default seems like a 
particularly good idea, to further alert anyone who has been ignoring the 
warnings about implicit int that semantics will change incompatibly.

In cases where the standard requires a diagnostic, some are errors, some 
are pedwarns-by-default or unconditional pedwarns, some are 
pedwarns-if-pedantic - the choice depending on how suspicious the 
construct in question is and whether it corresponds to a meaningful 
extension (this is not making an automatic choice for every such situation 
in the standard, it's a case-by-case judgement by maintainers).  By now, 
the cases discussed in this thread are sufficiently suspicious - 
sufficiently likely to result in unintended execution at runtime (not, of 
course, reliably detected because programs with such dodgy code are very 
unlikely to have thorough automated tests covering all their code) - that 
is it in the interests of users for them to be errors by default (for C99 
and later modes, in the cases that were valid in C89).

It might also make sense to review other pedwarns-by-default and 
unconditional pedwarns to consider if any of those should be errors by 
default, though I suspect most of those are less significant.

Enabling some of -Wall by default (as warnings, not errors) might well 
also be beneficial to users, though case would be needed to exclude those 
warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
positives that are hard to fix - not all of -Wall is for code that is 
objectively suspicious independent of the chosen coding style.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 17:08:18 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> CC: Jakub Jelinek <jakub@redhat.com>, <gabravier@gmail.com>,
> 	<jwakely.gcc@gmail.com>, <fweimer@redhat.com>, <gcc@gcc.gnu.org>,
> 	<arsen@aarsen.me>
> 
> On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> 
> > That is not the case we are discussing, AFAIU.  Or at least no one has
> > yet explained why accepting those old K&R programs will adversely
> > affect the ability of GCC to compile C2x programs.
> 
> At block scope,
> 
>   auto x = 1.5;
> 
> declares x to have type double in C2x (C++-style auto), but type int in 
> C89 (and is invalid for versions in between).  In this case, there is an 
> incompatible semantic change between implicit int and C++-style auto.  

So in this case, I'm okay with GCC changing the default behavior at
some point, such that the above is interpreted as C2x mandates, which
will then break some old programs.  This is another example of a "good
reason" for changing behavior in backward-incompatible ways.

But please note that emitting an error is not required, at least in my
book.  I assume GCC emits a warning about this already, and that
should be enough, until such time as you decide to adopt the C2x
interpretation of that by default -- without going through the
intermediate stage of erroring out by default.

> Giving an error before we make -std=gnu2x the default seems like a 
> particularly good idea, to further alert anyone who has been ignoring the 
> warnings about implicit int that semantics will change incompatibly.

FWIW, I don't see a reason to give an error.

> Enabling some of -Wall by default (as warnings, not errors) might well 
> also be beneficial to users, though case would be needed to exclude those 
> warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
> positives that are hard to fix - not all of -Wall is for code that is 
> objectively suspicious independent of the chosen coding style.

IMO and IME, anything is better than errors.  I presume everyone on
this list is familiar with the frustrating experience of having a
large program suddenly fail to build with some strange-looking error
message, which launches you down the rabbit hole of trying to
understand what happened and why.  And if that happens as part of
running the configure script (as I understand is one of the potential
victims of that), that is even scarier, because most people don't read
the configure script and don't always understand what is going on
there and why; it is also not very easy to debug.

So I urge the GCC developers to try to avoid errors as much as
possible, as long as GCC is capable to produce code with some widely
adopted semantics, and break backward compatibility only if otherwise
GCC will be unable to implement newer features.  (And to be pedantic,
I don't consider new warnings to be new features in this context.)

Re: More C type errors by default for GCC 14

[James K. Lowden]

On Tue, 9 May 2023 23:45:50 +0100
Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:

> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > We are currently using gcc 12 and specifying C11.  To experiment
> > with these stricter warnings and slowly address them, would we need
> > to build with a newer C version?
> 
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!

This, it seems to me, is the crux of the question.  Code that does not
conform to the standard should produce an error.  Code that can be
compiled correctly, per the specification, but might not be what the
user intended, is a candidate for a warning.  

If the proposed changes catch true errors -- not just dubious
constructs -- that were previously allowed, well, that's the price of
progress.  That's the compiler getting better at distinguishing between
code conformant and not.  

Section 2.1 "C Language" of the manual states that, with no option
specified on the command line, the default standard is -std=gnu17.  

Part of the proposal IIUC is to treat undeclared functions as an error.
Function prototypes have been required afaik since c99.  If
that's correct, then letting them pass without error is a mistake for
-std=c99 and above.  

As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
GNU extensions -- includes ignoring missing function prototypes?  That
to me would be an odd definition of "extension".  

The user who has old code that does not meet the c99 standard but Just
Works nonetheless has a direct route to compiling that code without
complaint: -std=c90.  It says so right there in the fine manual.  

It's that simple.  The code is either in spec and compiles without
error, or it is not and does not.  The only debate is over what "the
spec" is, and what warnings the user might want for conforming code.  

--jkl

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Thu, 11 May 2023 at 00:18, James K. Lowden <jklowden@schemamania.org> wrote:
>
> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>
> > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > > We are currently using gcc 12 and specifying C11.  To experiment
> > > with these stricter warnings and slowly address them, would we need
> > > to build with a newer C version?
> >
> > No, the proposed changes are to give errors (instead of warnings) for
> > rules introduced in C99. GCC is just two decades late in enforcing the
> > C99 rules properly!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.

That's not what the standard says.

>  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.

Technically, the standard only requires a diagnostic, and a warning is
a diagnostic. So strictly speaking, it's conforming to let them pass
with a warning. The question is whether that's really the best
behaviour for the majority of current users. At some point in the past
it was decided that warning and continuing by default was the best
choice. That might not still be true today.

> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".

I don't think that actually matters here.

> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.

Indeed.

> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.

Well, no, because issuing a warning for violations of the spec
conforms to the standard. So it's not that simple, we really do have
to decide whether to actually cause compilation failure for these
constraint violations, or just issue a diagnostic and continue.

Re: More C type errors by default for GCC 14

[Sam James]

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


"James K. Lowden" <jklowden@schemamania.org> writes:

> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>> > We are currently using gcc 12 and specifying C11.  To experiment
>> > with these stricter warnings and slowly address them, would we need
>> > to build with a newer C version?
>> 
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.  
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.  
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.  
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.  
>
> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".  
>
> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.  
>
> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.  

jwakely's already dispatched with these claims, but I'd note that
if this were the case, we'd all be arguing about whether Clang
is currently conformant.

(There is a fair point in all of this about how much we want to
consider some of these constructs extensions. I'm relieved to see
that e.g. implicit func. decls weren't ever considered "real"
GNU extensions, rather something which was added for compat. for
a while, rather than something deliberately and explicitly
supported as a GNU extension forever, even just for certain Cs.)


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

Re: More C type errors by default for GCC 14

[Po Lu]

jwakely.gcc@gmail.com (Jonathan Wakely) writes:

> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".

Only if your definition of valid C is ``strictly conforming to the ISO
Standard''.  I doubt there are many programs which fit such a
definition.

And anyway, GCC accepts many other constructs which can not be used in a
strictly conforming Standard C programs.  For example, the use of dollar
signs in identifiers.  Should we not also reject those, identifier names
with external linkage longer than thirty two characters, hex floats,
arithmetic on void pointers, zero-length arrays, statement expressions,
and so on?

> Accepting invalid code by default is a disservice to users. Those who
> need to compile invalid C code can use an extra option to allow it,
> the default should be to tell users their code is doing something bad.

The code is conforming, it simply relies on extensions to the Standard.
Implicit int does not break any strictly conforming program, so a C
implementation implemented it continues to be conforming, along with
those programs relying on implicit int.  See this wording in the
Standard:

  A conforming implementation may have extensions (including additional
  library functions), provided they do not alter the behavior of any
  strictly conforming program.

You are not trying to reject non-conforming C code.  You are, for better
or worse, trying to impose your personal preferences on users of GCC.

Let's debate the real problem at hand instead of using the Standard as a
boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
good idea.

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?
>
>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:
>
>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.
>
> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

Much of the thread (including the original post) does discuss that and
it's not limited to implicit-int.

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

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.

No, we're talking about "things which ISO C made invalid in 1999, but
GCC kept supporting for a while". We're discussing terminating that
support. The "standard" part here is not about deference to the standard
and claiming extensions can never be made, but rather that we're keeping
something which was explicitly removed.

>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

These aren't things which were in the standard and then got removed
because of how terrible they are. They're things that are considered
a part of GNU C as proper GNU extensions.

Note that, per the rest of the thread, the constructs we're discussing
here to be banned are not considered "proper GNU extensions".



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

Re: More C type errors by default for GCC 14

[Po Lu]

dje.gcc@gmail.com (David Edelsohn) writes:

> 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.

Oh please.  By this definition, every bug is a security issue.
What bugs have been caused by implicit int?

> 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.

You will simply make life annoying for people who already have working
code.  People do not like it when others do that!

If you make it too annoying to turn off the new diagnostics, you will
not convince people who have not stopped writing traditional C code to
stop doing so.

Instead, they will use an older version of GCC, or license a proprietary
compiler which allows them to keep writing use language as they always
did.  My organization eventually chose the latter when GCC removed
`-traditional', and to this day we continue to write code which relies
on float arithmetic being promoted to double, unsigned narrow types
being promoted to unsigned int, and string constants being writable.

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> dje.gcc@gmail.com (David Edelsohn) writes:
>
>> 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.
>
> Oh please.  By this definition, every bug is a security issue.
> What bugs have been caused by implicit int?
>
>> 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.
>
> You will simply make life annoying for people who already have working
> code.  People do not like it when others do that!
>
> If you make it too annoying to turn off the new diagnostics, you will
> not convince people who have not stopped writing traditional C code to
> stop doing so.
>
> Instead, they will use an older version of GCC, or license a proprietary
> compiler which allows them to keep writing use language as they always
> did.  My organization eventually chose the latter when GCC removed
> `-traditional', and to this day we continue to write code which relies
> on float arithmetic being promoted to double, unsigned narrow types
> being promoted to unsigned int, and string constants being writable.

Nobody here is suggesting that the ability to compile this code at
all would be removed. Throughout this thread, people discuss methods
like e.g. adding -fpermissive to allow it.

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

Re: More C type errors by default for GCC 14

[Po Lu]

jwakely.gcc@gmail.com (Jonathan Wakely) writes:

> 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.

I'm sorry you think that way.

> 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.

Vocal minority? Do you have any evidence to back this claim?

What I see is that some reasonable organizations have already chosen
other C compilers which are capable of supporting their existing large
bodies of C code that have seen significant investment over many years,
while others have chosen to revise their C code with each major change
to the language.

The organizations which did not wish to change their code did not
vocally demand changes to GCC after GCC became unsuitable, but quietly
arranged to license other compilers.

Those that continue write traditional C code know what they are doing,
and the limitations of traditional C do not affect the quality of their
code.  For example, on the Unix systems at my organization, the SGS is
modified so that it will not link functions called through a declaration
with no parameter specification with a different set of parameters than
it was defined with.

Naturally, the modified linker is not used to run configure scripts.

Re: More C type errors by default for GCC 14

[Sam James]

Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
>
>> 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.
>
> I'm sorry you think that way.
>
>> 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.
>
> Vocal minority? Do you have any evidence to back this claim?
>
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
>
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
>
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.

I think the group of people dedicated enough to patch their linker would
be able to pass a flag to the compiler to allow old constructs.

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> No, we're talking about "things which ISO C made invalid in 1999, but
> GCC kept supporting for a while". We're discussing terminating that
> support. The "standard" part here is not about deference to the standard
> and claiming extensions can never be made, but rather that we're keeping
> something which was explicitly removed.

Which is still an extension to the Standard, and a perfectly conforming
one at that.

The same could not be said about the lack of trigraphs, and keywords
such as `asm'.

> These aren't things which were in the standard and then got removed
> because of how terrible they are. They're things that are considered
> a part of GNU C as proper GNU extensions.

Once the Standard removed those features, the implementations in GNU C
became GNU extensions.  No amount of wordplay is going to change that.

In C99 and later dialects of C, GCC even issues a diagnostic upon
encountering implicit function declarations or implicit int, thereby
satisfying that requirement of the Standard.

> Note that, per the rest of the thread, the constructs we're discussing
> here to be banned are not considered "proper GNU extensions".

Really?  It is an implementation extension, the implementation being GNU
C.  It also seems rather arrogant to assume that you have the privilege
to ban others from writing code in a certain way.

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> Nobody here is suggesting that the ability to compile this code at
> all would be removed. Throughout this thread, people discuss methods
> like e.g. adding -fpermissive to allow it.

Here, I'm saying that making it annoying to compile such code is not
going to convince people to change the way they write.

Making it impossible to do so will make them look for some other C
compiler.  So you might as well not try.

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> I think the group of people dedicated enough to patch their linker would
> be able to pass a flag to the compiler to allow old constructs.

Unfortunately, we do not have the source code for our compiler.  Would
you care to ask people here to restore `gcc -traditional'?

Re: More C type errors by default for GCC 14

[Po Lu]

jwakely.gcc@gmail.com (Jonathan Wakely) writes:

> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!

The Standard requires that a diagnostic be issued upon encountering
certain kinds of invalid constructs.  Warnings are diagnostics.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely via Gcc <gcc@gcc.gnu.org> writes:

> On Wed, 10 May 2023, 03:32 Eli Zaretskii, <eliz@gnu.org> wrote:
>
>>
>> And then people will start complaining about GCC unnecessarily
>> erroring out, which is a compiler bug, since there's no problem
>> producing correct code in these cases.
>>
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?

Because keeping that from compiling will also keep this from compiling:

bar ()
{
  extern foo ();

  return foo ("42");
}

> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".

And so it should.  Because for every invalid piece of code you can think
of, there are hundereds or thousands of combinations that may as well be
valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
machine:

foo (ptr)
{
  register char *str;

  str = ptr;

  /* do stuff with str */

  puts (str);
}

/* In another translation unit.  */

bar ()
{
  foo ("42");
}

Re: More C type errors by default for GCC 14

[Eli Schwartz]

> Unfortunately, we do not have the source code for our compiler.  Would
> you care to ask people here to restore `gcc -traditional'?


This would appear to be a self-inflicted wound. If I understand the
chain of events properly...

- gcc drops support for -traditional

- you wish to use code that does the badness

- you purchase a proprietary compiler that permits it anyway
  - to avoid making it produce invalid results, you hack your linker

You'd rather hack your compiler, but you cannot do it because you
purchased a proprietary compiler and didn't purchase the rights to its
source code.

(BTW, there's a FOSS compiler that you can hack on if you like.)



That's all fine and well, you do you. What I do not understand is, two
things.

First of all, why are you calling this "traditional C"? It is not
"traditional C". It isn't C. It is not-C.

Second of all, why is this GCC's problem? You are not a user of GCC,
apparently.



Moreover, this discussion is not about -traditional! It's about
implicit-function-declaration. And implicit-function-declaration does
not have the same problem as -traditional, because
implicit-function-declaration ***WILL*** have a flag that permits people
who are users of GCC, and just want implicit-function-declaration back.

So you have exactly what you want out of this conversation. We concede.
C type errors by default will come with a flag to disable them.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

>> Unfortunately, we do not have the source code for our compiler.  Would
>> you care to ask people here to restore `gcc -traditional'?
>
>
> This would appear to be a self-inflicted wound. If I understand the
> chain of events properly...

The chain of events actually is:

  - The code was originally written for the BSD Unix cc.
  - Eventually, it started to be built with GCC, with -traditional.
  - GCC removes -traditional.
  - We are forced to find another C comppiler.

Note that I wasn't where I am when this started, so everything above is
second hand knowledge.

And finally, this:

>   - to avoid making it produce invalid results, you hack your linker

Which is essentially link-time lint, and not related to the subject at
hand.  I only mentioned it to make a point, which is that people writing
traditional C in this day and age are unlikely to make any mistakes
doing so.

> You'd rather hack your compiler, but you cannot do it because you
> purchased a proprietary compiler and didn't purchase the rights to its
> source code.
>
> (BTW, there's a FOSS compiler that you can hack on if you like.)

Which sadly does not support the code which we need to compile.
Clearly, turning GCC into a K&R compiler is not a very welcome idea
around here, so why would we hack on it?

> That's all fine and well, you do you. What I do not understand is, two
> things.
>
> First of all, why are you calling this "traditional C"? It is not
> "traditional C". It isn't C. It is not-C.

When the file names for the source files end with `.c' and `.h', and the
compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.

> Second of all, why is this GCC's problem? You are not a user of GCC,
> apparently.

Because decisions arbitrarily made on GCC's part will simply result in
even more people deciding to find some other compiler.

The point being that people sufficiently dedicated to their existing
code to not have changed in over 30 years will not respond to such
changes by changing their code.  They are much more likely to look for
some other compiler instead.

> And implicit-function-declaration does not have the same problem as
> -traditional, because implicit-function-declaration ***WILL*** have a
> flag that permits people who are users of GCC, and just want
> implicit-function-declaration back.

And remember that `-traditional' DID exist for a certain amount of time.
Then it was removed.  So in addition to annoying a lot of people, what
guarantees that -Wno-implicit will not be removed in the future, after
the proposed changes are made?

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/10/23 11:56 PM, Po Lu wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
> 
>>> Unfortunately, we do not have the source code for our compiler.  Would
>>> you care to ask people here to restore `gcc -traditional'?
>>
>>
>> This would appear to be a self-inflicted wound. If I understand the
>> chain of events properly...
> 
> The chain of events actually is:
> 
>   - The code was originally written for the BSD Unix cc.
>   - Eventually, it started to be built with GCC, with -traditional.
>   - GCC removes -traditional.
>   - We are forced to find another C comppiler.


Right, this is what I said. Although your bullet points 1 and 2 don't
really have much of anything to do with it.

In between points 3 and 4, I noted that you wish to *use* such bad code.
I didn't say you wish to write it, merely that you wish to use it
(without judging when it was written).


> Note that I wasn't where I am when this started, so everything above is
> second hand knowledge.
> 
> And finally, this:
> 
>>   - to avoid making it produce invalid results, you hack your linker
> 
> Which is essentially link-time lint, and not related to the subject at
> hand.  I only mentioned it to make a point, which is that people writing
> traditional C in this day and age are unlikely to make any mistakes
> doing so.


Absolutely! It's a very good point. It's a point that people writing
traditional not-C in this day and age are doing so with highly complex
toolchains they have personally written to do things that no non-bespoke
toolchain does. As such, they are unaffected by any and all decisions
GCC makes. But if they were affected by such decisions, they would have
the technical knowledge to modify GCC to suit themselves.


>> You'd rather hack your compiler, but you cannot do it because you
>> purchased a proprietary compiler and didn't purchase the rights to its
>> source code.
>>
>> (BTW, there's a FOSS compiler that you can hack on if you like.)
> 
> Which sadly does not support the code which we need to compile.
> Clearly, turning GCC into a K&R compiler is not a very welcome idea
> around here, so why would we hack on it?


But your bespoke toolchain did not support the code which you need to
compile either. That's why you began hacking on it at all, to suit your
needs.

So if neither GCC nor your bespoke toolchain support the code you need
to compile, and you must modify *something* to suit yourself, then it is
definitely possible to do it for GCC instead.

I don't see what the welcome for making these modifications into the
default flagship experience for the entire free software ecosystem, has
to do with your being welcome to hack on GCC for your own personal use.

Do you feel welcome by your proprietary vendor, who refuses to let you
touch it at all by withholding source code?


>> That's all fine and well, you do you. What I do not understand is, two
>> things.
>>
>> First of all, why are you calling this "traditional C"? It is not
>> "traditional C". It isn't C. It is not-C.
> 
> When the file names for the source files end with `.c' and `.h', and the
> compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.


BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
/usr/bin/python.

...

No, the criteria for whether something constitutes a given programming
language are not "the file extension says so" or "the compiler name says
so".

A programming language is defined by the syntax and meaning of that
programming language.

(If we were to replace this conversation with a definition of what
constitutes python, then as a scripted language, all files without file
extensions could be python scripts. And similarly, people play
interesting games with C files by naming them unconventional names and
passing -xc to the compiler. File extension autodetection isn't everything.)


>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> Because decisions arbitrarily made on GCC's part will simply result in
> even more people deciding to find some other compiler.
> 
> The point being that people sufficiently dedicated to their existing
> code to not have changed in over 30 years will not respond to such
> changes by changing their code.  They are much more likely to look for
> some other compiler instead.


Well no, because if they are sufficiently dedicated to their existing
code to not have changed in over 30 years then they are writing c89 code
and passing -std=c89, and this is acceptable as far as GCC is concerned
and their code will still compile.

So they won't feel inclined to find some other compiler, and quite
frankly, if they were doing the right thing in accordance with the
standard way to use the language they prefer to use, then they probably
will not notice that GCC changed anything?


>> And implicit-function-declaration does not have the same problem as
>> -traditional, because implicit-function-declaration ***WILL*** have a
>> flag that permits people who are users of GCC, and just want
>> implicit-function-declaration back.
> 
> And remember that `-traditional' DID exist for a certain amount of time.
> Then it was removed.  So in addition to annoying a lot of people, what
> guarantees that -Wno-implicit will not be removed in the future, after
> the proposed changes are made?


What guarantees of the future do you have for anything?

What guarantees do you have that a meteor won't hit Earth and wipe out
all human life in a great catastrophe?

What guarantees do you have that GCC will still be run by the current
maintainers?

What guarantees do you have that GCC will still be maintained at all?

What guarantees do you have that GCC won't decide next year that they
are deleting all support for std > c89, making -traditional the default,
and becoming a historical recreation society?

What guarantees do you have that GCC won't decide next year that they
are deleting all support for std < c23, mandating that everyone upgrade
to the very latest std that isn't even fully implemented today?

What guarantees do you have that reality exists as you think of it?
Maybe you are a pink elephant and computers are a figment of your
imagination.

...

I think that what-ifs aren't the most productive use of our time. The
current proposal provides for -std=c89 and similar, so the current
proposal does not cause current GCC users to be unable to use GCC after
the proposed change.

If a future proposal causes current GCC users to be unable to use GCC
after the future proposal is implemented, then, and only then, should we
worry about whether it will be possible to use GCC. Then, and only then,
will a threat to prevent doing so have actually materialized.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 12:46 AM, Eli Schwartz wrote:
> On 5/10/23 11:56 PM, Po Lu wrote:
>> And remember that `-traditional' DID exist for a certain amount of time.
>> Then it was removed.  So in addition to annoying a lot of people, what
>> guarantees that -Wno-implicit will not be removed in the future, after
>> the proposed changes are made?
> 
> 
> What guarantees of the future do you have for anything?
> 
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
> 
> What guarantees do you have that GCC will still be run by the current
> maintainers?
> 
> What guarantees do you have that GCC will still be maintained at all?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
> 
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.
> 
> ...
> 
> I think that what-ifs aren't the most productive use of our time. The
> current proposal provides for -std=c89 and similar, so the current
> proposal does not cause current GCC users to be unable to use GCC after
> the proposed change.
> 
> If a future proposal causes current GCC users to be unable to use GCC
> after the future proposal is implemented, then, and only then, should we
> worry about whether it will be possible to use GCC. Then, and only then,
> will a threat to prevent doing so have actually materialized.


P.S. No, it is not realistic that GCC will remove support for a language
feature of c89, until and unless GCC removes support for -std=c89. So I
do not know why you are talking about -Wno-implicit. That isn't the
question, that's not what's up for debate here. The question is whether
GCC will drop support for -std=c89, with all the language functionality
that encompasses (including defaulting to not issuing fatal diagnostics
when you use it, or indeed issuing diagnostics at all).

So please restate your question, as such:

> And remember that `-traditional' DID exist for a certain amount of
> time. Then it was removed.  So in addition to annoying a lot of
> people, what guarantees that -std=c89 will not be removed in the
> future, after the proposed changes are made?



-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 14:37:50 -0400
> From: "James K. Lowden" <jklowden@schemamania.org>
> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>
> 
> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> 
> > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > > We are currently using gcc 12 and specifying C11.  To experiment
> > > with these stricter warnings and slowly address them, would we need
> > > to build with a newer C version?
> > 
> > No, the proposed changes are to give errors (instead of warnings) for
> > rules introduced in C99. GCC is just two decades late in enforcing the
> > C99 rules properly!
> 
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.

That's not what the standard says, and that's not how GCC behaves.
GCC has options to enforce the standard, but other than that, it
doesn't reject extensions and deviations from the standard.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 23:14:20 -0400
> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> 
> Second of all, why is this GCC's problem? You are not a user of GCC,
> apparently.

He is telling you that removing support for these old features, you
draw users away from GCC and towards proprietary compilers.

One of the arguments in this thread _for_ dropping that support was
that by not rejecting those old programs, GCC draws some users away
from GCC.  He is telling you that this change will, perhaps, draw some
people to GCC, but will draw others away from GCC.  The difference is
that the former group will start using Clang, which is still free
software (at least some of its versions), whereas the latter group has
nowhere to go but to proprietary compilers.  So the FOSS community
will have suffered a net loss.  Something to consider, I think.

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Right, this is what I said. Although your bullet points 1 and 2 don't
> really have much of anything to do with it.
>
> In between points 3 and 4, I noted that you wish to *use* such bad code.
> I didn't say you wish to write it, merely that you wish to use it
> (without judging when it was written).

[...]

> Absolutely! It's a very good point. It's a point that people writing
> traditional not-C in this day and age are doing so with highly complex
> toolchains they have personally written to do things that no non-bespoke
> toolchain does. As such, they are unaffected by any and all decisions
> GCC makes. But if they were affected by such decisions, they would have
> the technical knowledge to modify GCC to suit themselves.

Upper management types performed a cost analysis and decided that it
would be more appropriate to license another C compiler.  Please don't
expect that only technical ability affects decisions made in the real
world.

> But your bespoke toolchain did not support the code which you need to
> compile either. That's why you began hacking on it at all, to suit your
> needs.
>
> So if neither GCC nor your bespoke toolchain support the code you need
> to compile, and you must modify *something* to suit yourself, then it is
> definitely possible to do it for GCC instead.
>
> I don't see what the welcome for making these modifications into the
> default flagship experience for the entire free software ecosystem, has
> to do with your being welcome to hack on GCC for your own personal use.
>
> Do you feel welcome by your proprietary vendor, who refuses to let you
> touch it at all by withholding source code?

No, I do not.  I can not speak for my management.

But I also do not feel any welcome from a group of developers who are
interested in breaking other code, some of which I have written for
myself, and then religiously defend their decisions.

In short, I do not like being told what to do with my own code!

> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
> /usr/bin/python.
>
> ...
>
> No, the criteria for whether something constitutes a given programming
> language are not "the file extension says so" or "the compiler name says
> so".
>
> A programming language is defined by the syntax and meaning of that
> programming language.

OK, and the Portable C Compiler from Bell Labs followed one such
definition of its syntax and meaning.

ANSI and ISO simply define several such variants of the C language,
collectively known as Standard C.  1st edition K&R defines another, and
each compiler, in practice, defines its own.  Just like there are
different varieties of English, or perhaps German.

> (If we were to replace this conversation with a definition of what
> constitutes python, then as a scripted language, all files without file
> extensions could be python scripts. And similarly, people play
> interesting games with C files by naming them unconventional names and
> passing -xc to the compiler. File extension autodetection isn't everything.)

This is pure pedantry.  My point is:

  If it looks like a duck, and quacks like a duck, then it is a duck.

or, IOW:

  If it looks like C, compiles in a C compiler, then it is C.

> Well no, because if they are sufficiently dedicated to their existing
> code to not have changed in over 30 years then they are writing c89 code
> and passing -std=c89, and this is acceptable as far as GCC is concerned
> and their code will still compile.

They are not writing ``C89'' code.  They are writing ``GNU99'', or perhaps
``GNU11'' code.

> So they won't feel inclined to find some other compiler, and quite
> frankly, if they were doing the right thing in accordance with the
> standard way to use the language they prefer to use, then they probably
> will not notice that GCC changed anything?

What gives you the right to dictate what the Right Thing is and what is
not?

> What guarantees of the future do you have for anything?
>
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
>
> What guarantees do you have that GCC will still be run by the current
> maintainers?
>
> What guarantees do you have that GCC will still be maintained at all?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
>
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

You are arguing to absurdity.

> I think that what-ifs aren't the most productive use of our time. The
> current proposal provides for -std=c89 and similar, so the current
> proposal does not cause current GCC users to be unable to use GCC after
> the proposed change.

Perhaps you must try writing a program which strictly conforms to the
Standard, since you seem to be asking everyone to write in such a way.

My point is that there is a very significant body of economically
valuable code written in the dialect of C actually implemented by GCC,
as it stands right now, just as there is a significant (albiet not so
much) body of traditional C (K&R) code.

If GCC is no longer able to compile such code, it will attract the
legitimate anger of its users.  And making users angry is not productive
in any way.

> If a future proposal causes current GCC users to be unable to use GCC
> after the future proposal is implemented, then, and only then, should we
> worry about whether it will be possible to use GCC. Then, and only then,
> will a threat to prevent doing so have actually materialized.

Parse error.

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> P.S. No, it is not realistic that GCC will remove support for a language
> feature of c89, until and unless GCC removes support for -std=c89. So I
> do not know why you are talking about -Wno-implicit. That isn't the
> question, that's not what's up for debate here. The question is whether
> GCC will drop support for -std=c89, with all the language functionality
> that encompasses (including defaulting to not issuing fatal diagnostics
> when you use it, or indeed issuing diagnostics at all).

Because in the real world, almost nobody writes strictly conforming ANSI
C.  Some people do want to mix declarations with statements.  Some
people do want non-local goto, typeof, zero length arrays, arithmetic on
void pointers, asm volatile, and so on.  And at the same time, they also
want to be able to use features such as various declarations with only a
storage class specifier.

All of which are presently implemented by GCC.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Thu, 11 May 2023 00:46:23 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> 
> > And remember that `-traditional' DID exist for a certain amount of time.
> > Then it was removed.  So in addition to annoying a lot of people, what
> > guarantees that -Wno-implicit will not be removed in the future, after
> > the proposed changes are made?
> 
> 
> What guarantees of the future do you have for anything?
> 
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
> 
> What guarantees do you have that GCC will still be run by the current
> maintainers?
> 
> What guarantees do you have that GCC will still be maintained at all?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
> 
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

Please be serious, and please don't mock your opponents.  This is a
serious discussion of a serious subject, not a Twitter post.

Back to the subject: the guarantees I would personally like to have is
that the current GCC development team sees backward compatibility as
an important goal, and will try not to break old programs without very
good technical reasons.  At least in Emacs development, that is the
consideration that is very high on our priority list when making
development decisions.  It would be nice if GCC (and any other GNU
project, for that matter) would do the same, because being able to
upgrade important tools and packages without fear is something users
value very much.  Take it from someone who uses GCC on various
platforms since version 1.40.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Thu, 11 May 2023, 03:18 Po Lu, <luangruo@yahoo.com> wrote:

>  It also seems rather arrogant to assume that you have the privilege
> to ban others from writing code in a certain way.
>

This is about a change in defaults. There would be options to continue
compiling that code. It would not be banned, so the histrionics are
unnecessary.

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 18:28, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 17:58:16 +0200
>> From: David Brown via Gcc <gcc@gcc.gnu.org>
>>
>>> In any case, I was not not talking about bug-compatibility, I was
>>> talking about being able to compile code which GCC was able to compile
>>> in past versions.  Being able to compile that code is not a bug, it's
>>> a feature.
>>
>> No, being able to compile /incorrect/ code by default is a bug.  It is
>> not helpful.
> 
> I actually agree; we just have different definitions of "incorrect".
> 

Fair enough.

>> I've seen this kind of argument many times - "The compiler used to
>> accept my code and give the results I wanted, and now newer compiler
>> versions make a mess of it".
> 
> But we are not talking about some random code that just happened to
> slip through cracks as a side effect of the particular implementation.
> We are talking about code that was perfectly valid, had well-defined
> semantics, and produced a working program.  I don't care about the
> former; I do care about the latter.

How would you know that the code had perfectly valid, well-defined 
semantics?

I've had the dubious pleasure of trying to maintain and update code 
where the previous developer had a total disregard for things like 
function declaration - he really did dismiss compiler complaints about 
implicit function declarations as "only a warning".  The program worked 
as he expected, for the most part.  But that was despite many functions 
being defined in one part of the code with one set of parameters (number 
and type), and called elsewhere with a different set - sometimes more 
than one selection of parameter types in the same C file.

Insisting on proper function declarations and removing implicit int does 
not guarantee that such messes won't happen - but it /does/ reduce some 
of the opportunities to do so accidentally.

> 
>> If the gcc developers really were required to continue to compile /all/
>> programs that compiled before, with the same results, then the whole gcc
>> project can be stopped.
> 
> You will have to explain this to me.  Just stating this is not enough.
> How will accepting K&R stop GCC development?
> 

People write incorrect code all the time.  Studies have shown that 
pretty much any sizeable C or C++ program - including gcc itself - 
contain undefined behaviour but rely on particular results from that. 
Lax interpretation and long outdated syntaxes do not, in themselves, 
imply undefined behaviour or incorrect code - but they make it far 
easier to accidentally have such errors, and to cover up such errors. 
(That's why they were removed in the first place.)

If a compiler is required to continue to compile every program that a 
previous version compiled, where the developer was satisfied that the 
program worked as expected, then the only way to guarantee that is to 
stop changing and improving gcc.

I agree that accepting fully correct programs written in K&R C would not 
limit the future development of gcc.  But how many programs written in 
K&R C, big enough and important enough to be relevant today, are fully 
correct?  I'd be surprised if you needed more than one hand to count 
them.  I would expect subtle errors and assumptions to flourish - with 
typical examples being signed integer arithmetic overflows and abuses of 
pointer casts and invalid mixing of pointer and integer types.

Continuing to give developers what they expect, rather than what the 
standards (and gcc extensions) guarantee, is always an issue for 
backwards compatibility.  Each new version of gcc can, and sometimes 
does, "break" old code - code that people relied on before, but was 
actually incorrect.  This is unavoidable if gcc is to progress.

That is why I suggested that a flag such as "-fold-code" that enables 
long outdated syntaxes should also disable the kind of optimisations 
that are most likely to cause issues with old code, and should enable 
semantics chances to match likely assumptions in such code.  I don't 
believe in the existence of correct K&R C code - but I /do/ believe in 
the importance of some K&R C code despite its errors.


> As for the two's complement wrapping example: I'm okay with having
> this broken because some useful feature requires to modify the basic
> arithmetics and instructions emitted by GCC in a way that two's
> complement wrapping can no longer be supported.  _That_ is exactly an
> example of a "good reason" for backward incompatibility: GCC must do
> something to compile valid programs, and that something is
> incompatible with old programs which depended on some de-facto
> standard that is nowadays considered UB.  

The problem for backwards compatibility and continuing to compile old 
code is that these things were /always/ UB - but they were, as you say, 
viewed as de-facto.

> But the case in point is not
> like that, AFAIU: in this case, GCC will deliberately break a program
> although it could compile it without adversely affecting its output
> for any other valid program.  To me, this would be an arbitrary
> decision of the GCC developers to break someone's code that has no
> "good reasons" which I could understand and respect, let alone accept.
> 

I think we have already agreed to disagree on what reasons count as 
"good" here, even though we agree that good reasons are required.

>> The only way to ensure perfect backwards compatibility would be to
>> stop development, and no longer release any new versions of the
>> compiler.  That is the logical consequence of "it used to compile
>> (with defaults or a given set of flags), so it should continue to
>> compile (with these same flags)" - assuming "compile" here means
>> "giving the same resulting behaviour in the executable" rather than
>> just "giving an executable that may or may not work".
> 
> This is not the logical consequence, this is reductio ad absurdum, a
> kind of strawman.  There's no need to go to such extremes, because
> "good reasons" for breaking backward compatibility do exist.  I'm a
> co-maintainer of GNU Emacs, a program that attempts not to break
> habits of users burned into their muscle memories for the last 30
> years; don't you think I know a bit what I'm talking about?
> 

"Knowing what you are talking about" is not the same thing as being 
correct.  But I think our key disagreements here are a matter of 
opinion, not fact - "correct" is not an appropriate term for an opinion. 
  We are looking at things from a different viewpoint, which will 
naturally be coloured by our experiences.  So to be clear, I fully 
understand your opinion and viewpoint here - I just don't think it 
should be the philosophy for gcc going forward.

It is a good thing that we can express and exchange these opinions. 
Ultimately, I suppose it is the gcc steering committee that will decide 
(the length of this thread suggests it is too important for developers 
alone).  I don't know about you, but I know that /I/ have absolutely no 
say or vote in the process - I am not involved in gcc development. 
However, I think it is good that a wide variety of people are able to 
give their thoughts, ideas and opinions, and I hope it helps the people 
who will make the decisions in the end.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Thu, 11 May 2023, 07:11 Eli Zaretskii via Gcc, <gcc@gcc.gnu.org> wrote:

> > Date: Wed, 10 May 2023 23:14:20 -0400
> > From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> >
> > Second of all, why is this GCC's problem? You are not a user of GCC,
> > apparently.
>
> He is telling you that removing support for these old features, you
> draw users away from GCC and towards proprietary compilers.
>


Nobody is removing support for them though.



> One of the arguments in this thread _for_ dropping that support was
> that by not rejecting those old programs, GCC draws some users away
> from GCC.  He is telling you that this change will, perhaps, draw some
> people to GCC, but will draw others away from GCC.  The difference is
> that the former group will start using Clang, which is still free
> software (at least some of its versions), whereas the latter group has
> nowhere to go but to proprietary compilers.  So the FOSS community
> will have suffered a net loss.  Something to consider, I think.
>

Yes, because switching to a different compiler is much easier and less
disruptive than [checks notes] adding some additional options to a makefile.

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

None of these result in a whisper-level warning before a severe but
difficult to detect breakage.

>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:

All of the features in question actively break programs (because they
allow entirely wrong code to be emitted).

>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.

> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

It is.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> writes:
>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii, <eliz@gnu.org> wrote:
>>
>>>
>>> And then people will start complaining about GCC unnecessarily
>>> erroring out, which is a compiler bug, since there's no problem
>>> producing correct code in these cases.
>>>
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>
> Because keeping that from compiling will also keep this from compiling:
>
> bar ()
> {
>   extern foo ();
>
>   return foo ("42");
> }

Good.  The above code is nonsense, the chances that foo will be
incorrectly called are high.

>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> And so it should.  Because for every invalid piece of code you can think
> of, there are hundereds or thousands of combinations that may as well be
> valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
> machine:
>
> foo (ptr)
> {
>   register char *str;
>
>   str = ptr;
>
>   /* do stuff with str */
>
>   puts (str);
> }
>
> /* In another translation unit.  */
>
> bar ()
> {
>   foo ("42");
> }

What is this meant to produce?

This is, at best, a "works by coincidence", rather than being code
anyone should be writing.

Such code is already written, when building it, pass -fpermissive.
You benefit from the error otherwise.

(and no, this isn't an issue of style, the code in question *does not*
convey sufficient information for the compiler to always do the right
thing)

Have a lovely day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: David Brown <david.brown@hesbynett.no>
> Date: Thu, 11 May 2023 08:52:03 +0200
> 
> > But we are not talking about some random code that just happened to
> > slip through cracks as a side effect of the particular implementation.
> > We are talking about code that was perfectly valid, had well-defined
> > semantics, and produced a working program.  I don't care about the
> > former; I do care about the latter.
> 
> How would you know that the code had perfectly valid, well-defined 
> semantics?

The programmer who wants to keep that code will know (or at least
he/she should).

> I've had the dubious pleasure of trying to maintain and update code 
> where the previous developer had a total disregard for things like 
> function declaration - he really did dismiss compiler complaints about 
> implicit function declarations as "only a warning".  The program worked 
> as he expected, for the most part.  But that was despite many functions 
> being defined in one part of the code with one set of parameters (number 
> and type), and called elsewhere with a different set - sometimes more 
> than one selection of parameter types in the same C file.

In this situation, where you take responsibility of a program someone
else wrote, and consider its code to be badly or unsafely written, TRT
is to modify the program to use more modern techniques that you
understand and support.  Compiler warnings and your own knowledge of
valid C will guide you in this.

My problem is not with the situation you described, it's with a case
that the "previous" maintainer remains the current maintainer, and/or
for some reason rewriting the code is either impractical or not the
best alternative for other reasons.

> If a compiler is required to continue to compile every program that a 
> previous version compiled, where the developer was satisfied that the 
> program worked as expected, then the only way to guarantee that is to 
> stop changing and improving gcc.

There should be no such requirement.  If addition of new features or
support for the evolving standards mean GCC must break old UB-style
code, that is fully justified and understandable.  What is _not_
justified, IMO, is breaking old programs without any such technical
reasons, just because we think they are better off broken.  IOW, as
long as being able to compile those old programs in the same old way
doesn't get in the way of being able to compile valid programs, the
old code should remain unbroken.

> I agree that accepting fully correct programs written in K&R C would not 
> limit the future development of gcc.  But how many programs written in 
> K&R C, big enough and important enough to be relevant today, are fully 
> correct?  I'd be surprised if you needed more than one hand to count 
> them.

For the purpose of this discussion, the "how many" question is not
interesting.  If there is an incorrect K&R program, the results and
consequences of this incorrectness are on the maintainers of those
programs, not on the GCC team.  If some of those incorrect programs
break because of some valid development in GCC, so be it.

But the decision to make a warning to be an error is not dictated by
GCC development and its needs to compile valid programs, it is
dictated by other, largely non-technical considerations.  I'm saying
that these considerations are not reasons good enough for breaking
those old programs.

> Continuing to give developers what they expect, rather than what the 
> standards (and gcc extensions) guarantee, is always an issue for 
> backwards compatibility.  Each new version of gcc can, and sometimes 
> does, "break" old code - code that people relied on before, but was 
> actually incorrect.  This is unavoidable if gcc is to progress.

It is indeed unavoidable, and a fact of life.  All I'm saying is that
we as developers should try to minimize these breakages as much as
possible, without hampering new developments too much.

> That is why I suggested that a flag such as "-fold-code" that enables 
> long outdated syntaxes should also disable the kind of optimisations 
> that are most likely to cause issues with old code, and should enable 
> semantics chances to match likely assumptions in such code.  I don't 
> believe in the existence of correct K&R C code - but I /do/ believe in 
> the importance of some K&R C code despite its errors.

The problem, as you well know, is that when a large software package
fails to build, it is not immediately clear what is the reason for
that.  We here discuss a single such reason, but in reality no one
tells you that the build fails because the new version of GCC now
rejects code it accepted in the previous version.  The upgrade that
installed the new GCC will typically update dozens of other system
components, many of which could be the culprit.  Just understanding
that the reason is GCC and its rejection of certain constructs is a
job that can take hours full of frustration and hair-pulling.  This is
what I think we as developers need to avoid as much as possible.  Once
you understand the reason, fixing it with a compiler switch might be
relatively simple, at least in many cases, but the problem is the
effort it takes to realize that the option is all you need.  There are
no good ways of making that option discoverable enough to make this
process significantly easier.

> "Knowing what you are talking about" is not the same thing as being 
> correct.  But I think our key disagreements here are a matter of 
> opinion, not fact - "correct" is not an appropriate term for an opinion. 
>   We are looking at things from a different viewpoint, which will 
> naturally be coloured by our experiences.  So to be clear, I fully 
> understand your opinion and viewpoint here - I just don't think it 
> should be the philosophy for gcc going forward.
> 
> It is a good thing that we can express and exchange these opinions. 
> Ultimately, I suppose it is the gcc steering committee that will decide 
> (the length of this thread suggests it is too important for developers 
> alone).  I don't know about you, but I know that /I/ have absolutely no 
> say or vote in the process - I am not involved in gcc development. 

Neither am I.  I'm investing my scarce time in this discussion in the
hope to convince the GCC development team and the steering committee
to see the downside of the proposal to reject those old programs where
GCC can still compile them without affecting modern valid C programs.
I think a warning is good enough in those case.

> However, I think it is good that a wide variety of people are able to 
> give their thoughts, ideas and opinions, and I hope it helps the people 
> who will make the decisions in the end.

Agreed.

Re: More C type errors by default for GCC 14

[David Brown]

On 11/05/2023 04:09, Po Lu via Gcc wrote:
> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
> 
>> 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.
> 
> I'm sorry you think that way.
> 
>> 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.
> 
> Vocal minority? Do you have any evidence to back this claim?
> 
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
> 
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
> 
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.
> 
> Naturally, the modified linker is not used to run configure scripts.
> 

Let's be absolutely clear here - gcc has been, and will continue to be, 
able to compile code according to old and new standards.  It can handle 
K&R C, right through to the cutting edge of newest C and C++ standards. 
It can handle semantic requirements such as two's complement wrapping 
and "anything goes" pointer type conversions - features that a lot of 
old code relies on but which are not documented or guaranteed behaviour 
for the vast majority of other compilers.  It can handle all these 
things - /if/ you pick the correct flags.

With the proposed changes, you can still compile old K&R code with gcc - 
if you give it the right flags.  No features are being removed - only 
the default flags are being changed.  If anyone is changing from gcc to 
other compilers because they think newer gcc does not support older 
code, then they are perhaps doing so from ignorance.

If some users are willing to change to different compilers, but 
unwilling to learn or use new flags in order to continue using their 
existing compiler after it changes its defaults, then perhaps gcc could 
pick different defaults depending on the name used for the executable? 
If it is invoked with the name "gcc-kr", then it could accept K&R code 
by default and have "-std=gnu90" (I believe that's the oldest standard 
option).  If it is invoked as "gcc", then it would reject missing 
function declarations, implicit int, etc., as hard errors.

Then these users could continue to use gcc, and their "new" compiler to 
handle their old code would be nothing more than a symbolic link.

David

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> None of these result in a whisper-level warning before a severe but
> difficult to detect breakage.

Really?  Why not run lint?

Besides, how is this any different from allowing people to write:

  extern int foo ();

or perhaps even

  extern int foo (struct bar *, long double _Complex);

when foo is something else?

> All of the features in question actively break programs (because they
> allow entirely wrong code to be emitted).

And they can also be used correctly.  GCC cannot tell the difference.
So why act as the judge, jury and executioner all rolled into one?

> It is.

It is not.

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Good.  The above code is nonsense, the chances that foo will be
> incorrectly called are high.

Yet lint (or scrutiny, as should be performed with any declaration,
implicit or not) makes sure that does not happen.

> What is this meant to produce?

It was just an example.  I'm not allowed to show any real code.

> This is, at best, a "works by coincidence", rather than being code
> anyone should be writing.

See what I said about being the judge, jury and executioner.

  (BTW, I thought implicit int was being discussed, not implicit
   function declarations, but here goes.)

The same problems will appear with _any_ extern declaration.  If you
remove implicit function declarations, people will simply paste:

  extern int foo ();

above the code which no longer compiles.
Or, if you force everyone to use prototypes,

  extern int foo (char *);

You will not be able to diagnose whether or not this declaration is
correct, because the definition will lie in another translation unit.
Except that in this case, no diagnostic will be issued at all when
the declared function is called.

The only place where you can truly fix mismatched declarations is the
linker (or collect2?)  GCC proper cannot do anything about it.

> Such code is already written, when building it, pass -fpermissive.
> You benefit from the error otherwise.
>
> (and no, this isn't an issue of style, the code in question *does not*
> convey sufficient information for the compiler to always do the right
> thing)

It does on reasonable machines for which the code was written.  I gave
two examples.  Perhaps the 386 is another.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> This is about a change in defaults. There would be options to continue
> compiling that code. It would not be banned, so the histrionics are
> unnecessary.

Please read the wording Sam used.  It clearly made reference to a ``ban''.

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Good.  The above code is nonsense, the chances that foo will be
>> incorrectly called are high.
>
> Yet lint (or scrutiny, as should be performed with any declaration,
> implicit or not) makes sure that does not happen.

Relying on human scrutiny when an algorithm can trivially deduce an
answer more quickly and more reliably (because even in the case that the
code you showed compiles, it assumes processor specific facts) has
historic precedent as being a bad idea.

I'm curious, though, about how lint checks for this.

>> What is this meant to produce?
>
> It was just an example.  I'm not allowed to show any real code.
>
>> This is, at best, a "works by coincidence", rather than being code
>> anyone should be writing.
>
> See what I said about being the judge, jury and executioner.
>
>   (BTW, I thought implicit int was being discussed, not implicit
>    function declarations, but here goes.)
>
> The same problems will appear with _any_ extern declaration.  If you
> remove implicit function declarations, people will simply paste:
>
>   extern int foo ();
>
> above the code which no longer compiles.
> Or, if you force everyone to use prototypes,
>
>   extern int foo (char *);

So be it.  The edge case still exists.  The normal case that I expect
most code is dealing with is much simpler: a missing include.  That case
is not discounted by the existence of misdeclarations across TUs.

> You will not be able to diagnose whether or not this declaration is
> correct, because the definition will lie in another translation unit.
> Except that in this case, no diagnostic will be issued at all when
> the declared function is called.
>
> The only place where you can truly fix mismatched declarations is the
> linker (or collect2?)  GCC proper cannot do anything about it.

There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
own code.

>> Such code is already written, when building it, pass -fpermissive.
>> You benefit from the error otherwise.
>>
>> (and no, this isn't an issue of style, the code in question *does not*
>> convey sufficient information for the compiler to always do the right
>> thing)
>
> It does on reasonable machines for which the code was written.  I gave
> two examples.  Perhaps the 386 is another.

Yes, indeed.  And code should keep working on those machines, because it
costs little to nothing to keep it working.  And it will if you pass
-fpermissive.

It seems to me plausible that the paragraph in the original proposal
that suggested -fpermissive might have been missed.

It is unfeasible for GCC to entirely stop compiling this code, there's
nobody that is advocating for doing that; however, the current default
of accepting this code in C is harmful to those who are writing new
code, or are learning C.

This seems like a good route to me - it facilitates both veterans
maintaining code and beginners just learning how to write C.

Have a lovely day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Thu, 11 May 2023 at 09:32, Po Lu <luangruo@yahoo.com> wrote:
>
> Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>
> > This is about a change in defaults. There would be options to continue
> > compiling that code. It would not be banned, so the histrionics are
> > unnecessary.
>
> Please read the wording Sam used.  It clearly made reference to a ``ban''.

It's a change in defaults. It's unhelpful if you're just going to jump
into a thread in the middle and start yelling without actually
understanding what you're yelling about.

Maybe start by reading the thread subject, which says "by default".

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Thu, 11 May 2023 at 09:31, Po Lu wrote:
>   (BTW, I thought implicit int was being discussed, not implicit
>    function declarations, but here goes.)

Then you're not paying attention, the very first mail in the thread
starts by saying:

TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.

Please educate yourself about the topic.

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Relying on human scrutiny when an algorithm can trivially deduce an
> answer more quickly and more reliably (because even in the case that the
> code you showed compiles, it assumes processor specific facts) has
> historic precedent as being a bad idea.

The algorithm in question is not much of an algorithm at all.  Rather,
it makes the blanket assumption that the lack of an explicit declaration
means the implicit declaration is incorrect, and that there is a correct
declaration in a header file somewhere.  That sounds rather premature,
don't you agree?

> I'm curious, though, about how lint checks for this.

Lint generates a lint library describing (among others) a description of
each function definition in every translation unit it checks.  It also
imports pregenerated lint libraries, such as those for the C and math
libraries.  All declarations are then checked against the lint libraries
being used.

> So be it.  The edge case still exists.  The normal case that I expect
> most code is dealing with is much simpler: a missing include.  That case
> is not discounted by the existence of misdeclarations across TUs.

I can't believe that the normal case is a missing include, because I see
`extern' declarations outside header files all the time (just look at
bash, and I believe one such declaration was just installed in Emacs.)

And how does that discount what I said people will do?  They will get
into the habit of placing:

  extern int foo ();

above each error.  Such declarations are also much more common than
implicit function declarations, and are more likely to lead to mistakes,
by the sole virtue of being 100% strictly conforming Standard C that
need not lead to any diagnostics, and thus, extra scrutiny from the
programmer.

The point is, such checks are the job of the linker and lint, because as
you yourself have observed, those are the only places where such bugs
can really be caught:

> There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
> own code.

[...]

> Yes, indeed.  And code should keep working on those machines, because it
> costs little to nothing to keep it working.  And it will if you pass
> -fpermissive.

And what prevents -fpermissive from being removed in the future, once
the folks here decide that -fpermissive must go the way of -traditional?

> It is unfeasible for GCC to entirely stop compiling this code, there's
> nobody that is advocating for doing that; however, the current default
> of accepting this code in C is harmful to those who are writing new
> code, or are learning C.

I expect people who write new code to pay even more scrutiny to
diagnostics from their C translator than usual, so the existing strategy
of issuing warnings should be sufficient.

> Have a lovely day.

You too.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> On Thu, 11 May 2023 at 09:31, Po Lu wrote:
>>   (BTW, I thought implicit int was being discussed, not implicit
>>    function declarations, but here goes.)
>
> Then you're not paying attention, the very first mail in the thread
> starts by saying:
>
> TL;DR: This message is about turning implicit-int,
                                       ^^^^^^^^^^^^
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.

It says right there that implicit-int is being discussed.  I missed the
part about implicit function declarations.

> Please educate yourself about the topic.

Evidently (from the rest of my follow-up), I already did.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 10:44:47 +0200
> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
> 
> the current default of accepting this code in C is harmful to those
> who are writing new code, or are learning C.

People who learn C should be advised to turn on all the warnings, and
should be educated not to ignore any warnings.  So this is a red
herring.

> This seems like a good route to me - it facilitates both veterans
> maintaining code and beginners just learning how to write C.

No, it prefers beginners (which already have the warnings, unless they
deliberately turn them off) to veterans who know what they are doing,
and can live with those warnings.  The right balance is exactly what
we have now: emitting warnings without breaking builds.

Re: More C type errors by default for GCC 14

[James K. Lowden]

On Wed, 10 May 2023 13:00:46 +0200
David Brown via Gcc <gcc@gcc.gnu.org> wrote:

> or that function calls always act as a 
> memory barrier.

Hi David, [off list]

Could you tell me more about that, and where I could read about it?  

I've only been using C since 1985, so just a beginner, I guess. ;-)
As a  matter of C semantics, I can't see how a function call could be
anything but a memory barrier.  The arguments have to be resolved before
the function is called, else there's no value to provide.  And the
function has to determine its return value prior to returning.  

I can imagine in the face of multithreading that things become murky,
but that's the nature of multithreading as commonly implemented.  It's
outside C semantics.  

I'm genuinely curious what it is your referring to, in case my
understanding is out of date.  

--jkl

Re: Re: More C type errors by default for GCC 14

[Peter0x44]

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

Hi,
After reading some of this discussion, I figured I should add my own support for this proposal. It seems to me very few (none?) of the people arguing against this change actually have a "horse in the race", and instead are appealing to some theoretical ancient legacy code maintainer who is both too lazy to fix usage of these 30 year invalid constructs, or add one build option to CFLAGS. The very worst consequence this has to anyone is a minor irritation, and the benefits are definitely significant.

I find the amount of misguided arguing here to be really immense. C has enough "foot guns" as is, and I'm sure the improvement will be appreciated by numerous C beginners. I will admit I used to have the tendency of ignoring warnings when code appeared to function fine, as a beginner.

I don't think I'm saying anything that isn't self evident, so I'll end this by saying the efforts expended to argue for this change are appreciated greatly, by me. Along with the rest of the work occurring on the compiler. Safer and friendlier defaults are a goal worth pursuing.

Thanks!
Peter D.

Re: More C type errors by default for GCC 14

[Jason Merrill]

On Wed, May 10, 2023 at 7:28 PM Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> On Thu, 11 May 2023 at 00:18, James K. Lowden <jklowden@schemamania.org> wrote:
> >
> > On Tue, 9 May 2023 23:45:50 +0100
> > Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:

> Technically, the standard only requires a diagnostic, and a warning is
> a diagnostic. So strictly speaking, it's conforming to let them pass
> with a warning. The question is whether that's really the best
> behaviour for the majority of current users. At some point in the past
> it was decided that warning and continuing by default was the best
> choice. That might not still be true today.

Indeed.  We have an assortment of levels of diagnostic.

error: always causes compilation to fail
   These are constructs for which either there's no reasonable
interpretation or no perceived benefit to accepting the code.

permerror: causes compilation to fail without -fpermissive
   Ill-formed constructs that we want to prevent in new code, but want
to allow in legacy code.

pedwarn on by default: warning by default, error with -pedantic-errors
   Ill-formed constructs that we think new code shouldn't use but are
ok to allow with a warning.

conditional pedwarn: warning with -pedantic, error with -pedantic-errors
   Ill-formed constructs that we support as an extension.

warnings on by default
  Patterns that are well-formed but almost certainly a mistake.

warnings in -Wall
  Patterns that are very likely a mistake.

warnings in -Wextra
  Patterns that are likely a mistake.

warnings you have to enable specifically
  Patterns that you want help to avoid.

Particular diagnostics can move between categories as perceptions
change over time.  My understanding of the proposal is that it
proposes to move these particular diagnostics from category 3 up to
category 2, both because code that relies on these patterns has gotten
less common and using these patterns by mistake has gotten more
harmful.

Jason

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc <gcc@gcc.gnu.org>
>> 
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning C.
>
> People who learn C should be advised to turn on all the warnings, and
> should be educated not to ignore any warnings.  So this is a red
> herring.

Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

>> This seems like a good route to me - it facilitates both veterans
>> maintaining code and beginners just learning how to write C.
>
> No, it prefers beginners (which already have the warnings, unless they
> deliberately turn them off) to veterans who know what they are doing,
> and can live with those warnings.

Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

> The right balance is exactly what we have now: emitting warnings
> without breaking builds.

I disagree - I think breaking builds here (remember, it takes 13 bytes
to fix them) is a much lower weight than the other case being shot in
the foot for an easily detectable and treatable error being made easily
missable instead, so I reckon the scale is tipped heavily towards the
veterans.

On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

Anyway - I'm not making that up - this circle of 'yeah the warnings
actually matter.. a lot' has happened with everyone I've tutored that
has had little to no contact with programming before (those who had more
contact have a higher respect for the word 'warning'), and it will keep
happening.

Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

On the other hand... I've been writing C for a long time, and you have
been doing so for a longer time.  We see 'error: ...' in an old codebase
for a pedantic (rather, by my definition, bare essential) check and we
know where to look to fix it or ignore it.

I build old, unfamiliar codebases all the time, and I've been using a
modified toolchain that enables the error proposed today for a while; my
peers and I, who are proposing this, have gone over thousands of old
codebases, I've fixed some personally, yet the percentage of those that
have been full-out broken by this change is small (configure scripts are
almost all of it, too; Po has mentioned that they use a laxer compiler
for those - we (Gentoo) test two compilers in order to detect when these
differences happen, but keep the results of the laxer one, and then try
to fix the code upstream - often it comes down to just running autoconf
-f, even).

This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the
likelyhood that you'll need to run `export CC='gcc -fpermissive'
CXX='g++ -fpermissive'` goes up the more you move towards old or more
corporate codebases, but, for a veteran, this is no cost at all.

Is it that much of a stretch to imagine that a maintainer of a codebase
that has not seen revisions to get it past K&R-esque practices would
know that they need to pass -std=c89 (or a variant of such), or even
-fpermissive - assuming that they could even spare to use GCC 14 as
opposed to 2.95?

As an anecdote, just recently I had to fix some code written for i686
CPUs, presumably for GCC 4.something or less, because the GCC I insist
on using (which is 13 and has been since 13.0 went into feature-freeze)
has started using more than the GPRs on that machine (which lead to hard
to debug crashes because said codebase does not enable the requisite CPU
extensions, or handle the requisite registers properly).  I think this
fits within the definition of 'worked yesterday, broke today'.  Should
that change be reverted?  Replacing it with -mmore-than-gprs would make
GCC more compatible with this old code.

I don't think so.

This is a sensitive codebase, and not just because it's written poorly,
but because it's a touchy thing it's implementing, any change in
compiler requires reverification.  The manifestation here has *no*
significance.

Mind you, this GCC change cost me more than someone seeing 'error:
implicit declaration of function ...' before adding -fpermissive would
pay when compiling their code with the wrong -std= value, because that
fails early, and unambiguously, and I had to fight a variety of nonsense
to actually debug this error.

... speaking of that, if one builds their codebase without -std=..,
they're risking more than just optimization changes breaking code that
relies on bad assumptions, they're also risking a change in language
semantics..

With all that to consider, is it *really* a significant cost to add
-fpermissive?  Would that cost not be massively overshadowed by the cost
of a compiler change?  It feels like it's a footnote compared to
checking whether added optimizations go against invalid assumptions
(which is, by the way, also rectified by adding more hard and easy
to see errors).

I expect no change in behavior from those that maintain these old
codebases, they know what they're doing, and they have bigger fish to
fry - however, I expect that this change will result in:

- A better reputation for GCC and the GCC project (by showing that we do
  care for code correctness),
- More new code being less error prone (by merit of simple errors being
  detected more often),
- Less 'cult knowledge' in the garden path,
- More responsible beginners, and
- Fewer people being able to effectively paint GNU and/or C/++ as the
  backwards crowd using a error-prone technique of yesteryear.

(and yes, optics matter)

Builds break.  Builds breaking cleanly is a treat compared to the usual
breakage.  At least this breaks the few that do break with a positive
outcome.

Have a lovely evening.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Relying on human scrutiny when an algorithm can trivially deduce an
>> answer more quickly and more reliably (because even in the case that the
>> code you showed compiles, it assumes processor specific facts) has
>> historic precedent as being a bad idea.
>
> The algorithm in question is not much of an algorithm at all.  Rather,
> it makes the blanket assumption that the lack of an explicit declaration
> means the implicit declaration is incorrect, and that there is a correct
> declaration in a header file somewhere.  That sounds rather premature,
> don't you agree?

Seems that the algorithm and I agree.  I don't see any use in the int()
guess that the compiler does, besides accepting old code (which makes it
candidate for -fpermissive).

>> I'm curious, though, about how lint checks for this.
>
> Lint generates a lint library describing (among others) a description of
> each function definition in every translation unit it checks.  It also
> imports pregenerated lint libraries, such as those for the C and math
> libraries.  All declarations are then checked against the lint libraries
> being used.

Ah, sounds similar to the LTO-time checking GCC can do.

>> So be it.  The edge case still exists.  The normal case that I expect
>> most code is dealing with is much simpler: a missing include.  That case
>> is not discounted by the existence of misdeclarations across TUs.
>
> I can't believe that the normal case is a missing include, because I see
> `extern' declarations outside header files all the time (just look at
> bash, and I believe one such declaration was just installed in Emacs.)
>
> And how does that discount what I said people will do?  They will get
> into the habit of placing:
>
>   extern int foo ();
>
> above each error.  Such declarations are also much more common than
> implicit function declarations, and are more likely to lead to mistakes,
> by the sole virtue of being 100% strictly conforming Standard C that
> need not lead to any diagnostics, and thus, extra scrutiny from the
> programmer.

We can diagnose these without invoking expensive machinery, unlike
mismatched declarations.

(theoretically, we could make an enabled-by-default Link Time Check mode
instead, I suppose... but we don't have that today, and it's certainly
more maintenance overhead than flipping a few defaults.)

I don't see why these not being diagnosed by default makes erroring on
the far simpler implicit case not valuable (even if it leads to people
just consciously inserting wrong declarations - that means they
acknowledged it and made a poor decision).

> The point is, such checks are the job of the linker and lint, because
> as you yourself have observed, those are the only places where such
> bugs can really be caught:

They can be caught in multiple places when obvious, such as when not
done explicitly.  These are two different errors.

>> There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
>> own code.
>
> [...]
>
>> Yes, indeed.  And code should keep working on those machines, because it
>> costs little to nothing to keep it working.  And it will if you pass
>> -fpermissive.
>
> And what prevents -fpermissive from being removed in the future, once
> the folks here decide that -fpermissive must go the way of -traditional?

I can't say.  I don't have memory of the traditional mode outside of
cpp.  The changes proposed today, however, are a few bits of entropy
relevant in a few places - the overhead is low.

Someone else would have to answer about why -traditional was replaced.

>> It is unfeasible for GCC to entirely stop compiling this code, there's
>> nobody that is advocating for doing that; however, the current default
>> of accepting this code in C is harmful to those who are writing new
>> code, or are learning C.
>
> I expect people who write new code to pay even more scrutiny to
> diagnostics from their C translator than usual, so the existing strategy
> of issuing warnings should be sufficient.

It's not, though.  That's why this is being conversed about.  Even
highly diligent people miss these (and even not-so-diligent people like
me do - I've had more of these found by me passing -flto than I did by
remembering to use an extra four -Werror=... flags, and that, of course,
misses the int(...) case - which is not a useful one, usually what I
meant there was (void), but strict-prototypes are a story for another
day or year).

Have a loevly evening.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Segher Boessenkool]

Hi Florian,

On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
>   are set to zero or 0xffffffff, resulting in crashes.  This can happen
>   if GCC synthesizes an implicit int declaration for a pointer-returning
>   function.
> 
> * Alleged code generation bugs because a function returning bool does
>   not set the entire register, as expected the caller.  This can happen
>   if GCC makes up a function declaration returning int for a function
>   that actually returns bool on x86-64.

Both of these cannot happen with better ABIs, by design.  Of course
every ABI has its own idiosyncrasies :-)

> I hope this makes things clearer.  I do think the current GCC defaults
> are needlessly frustrating, which is why I spent so much time on proving
> (from my perspective) that it should be feasible to change them.

Yes, I agree with this sentiment, and I think we can do a lot better
than we do now.

> We can get fairly close by injecting appropriate -Werror= options during

As you know, IMNSHO the only appropriate subset of -Werror= options is
the empty subset.

-Werror is for the user (the USER, not the build system) to ask "yes
please, I have all my priorities upside down, do fail compiling anything
that may look unexpected".  Most warnings are *heuristic*.  Other
warnings are for code that does not follow (modern) best practices.

But (most of) the diagnostics you propose to upgrade from warnings to
errors are not like this at all: they point out definite flaws, things
that just are not correct C code at all, and never were for that matter.
We always warn for those (without -Wall even) already, so upgrading
these to errors is a no-brainer really, as long as we also get
-fpermissive!


Segher

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 May 2023 23:14:20 -0400
>> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
>>
>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> He is telling you that removing support for these old features, you
> draw users away from GCC and towards proprietary compilers.
> 
> One of the arguments in this thread _for_ dropping that support was
> that by not rejecting those old programs, GCC draws some users away
> from GCC.  He is telling you that this change will, perhaps, draw some
> people to GCC, but will draw others away from GCC.  The difference is
> that the former group will start using Clang, which is still free
> software (at least some of its versions), whereas the latter group has
> nowhere to go but to proprietary compilers.  So the FOSS community
> will have suffered a net loss.  Something to consider, I think.


Except this thread is not arguing to remove support for -std=c89 as far
as I can tell?

The argument is that on newer values for -std (such as the one GCC
defaults to if no -std is specified), GCC should adapt its diagnostics
better for the std in question. These newer -stds should stop issuing a
warning diagnostic, and begin issuing an error diagnostic instead.

The latter group most certainly does have somewhere to go other than
proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
-fpermissive or -fold-code or whatever the case may be).

But I do not understand the comparison to -traditional. Which was
already removed, and already resulted in, apparently, at least one group
being so adamant on not-C that it switched to a proprietary compiler.
Okay, understood. But at this point that group is no longer users of
GCC... right?

So what is the moral of this story? To avoid repeating the story of
-traditional, and instead make sure that users of -std=c89 always have a
flag they can use to indicate they are writing old c89 code?

If so, then as far as I can tell, that was the original plan? The flag
already exists, even. And the original proposal was to provide another
flag that doesn't even restrict you to c89.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Sam James]

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


Eli Schwartz via Gcc <gcc@gcc.gnu.org> writes:

> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>>> Date: Wed, 10 May 2023 23:14:20 -0400
>>> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
>>>
>>> Second of all, why is this GCC's problem? You are not a user of GCC,
>>> apparently.
>> 
>> He is telling you that removing support for these old features, you
>> draw users away from GCC and towards proprietary compilers.
>> 
>> One of the arguments in this thread _for_ dropping that support was
>> that by not rejecting those old programs, GCC draws some users away
>> from GCC.  He is telling you that this change will, perhaps, draw some
>> people to GCC, but will draw others away from GCC.  The difference is
>> that the former group will start using Clang, which is still free
>> software (at least some of its versions), whereas the latter group has
>> nowhere to go but to proprietary compilers.  So the FOSS community
>> will have suffered a net loss.  Something to consider, I think.
>
>
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>

And I would not want to see that happen either, nor do I think Florian
would, or many of the other participants in this thread.

Indeed, for some projects, where it's hopeless^Wlots of work,
we're using -std=c89 or -std=gnu89 as appropriate - as already stated.

But most things are easy to fix.

Our interest is purely in making the default stricter for better UX,
reducing the net amount of these bugs in the wild, and avoiding
regressions when we fix these problems. Trying to remove C89 entirely
would, if nothing else, be needlessly antagonistic, but some of the
replies seem to act as if we have.


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

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 2:18 AM, Po Lu wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
>> Absolutely! It's a very good point. It's a point that people writing
>> traditional not-C in this day and age are doing so with highly complex
>> toolchains they have personally written to do things that no non-bespoke
>> toolchain does. As such, they are unaffected by any and all decisions
>> GCC makes. But if they were affected by such decisions, they would have
>> the technical knowledge to modify GCC to suit themselves.
> 
> Upper management types performed a cost analysis and decided that it
> would be more appropriate to license another C compiler.  Please don't
> expect that only technical ability affects decisions made in the real
> world.


I expect no such thing, but I do expect that people making decisions in
the real world acknowledge that ***they*** (and no one else) made those
decisions of their own volition.

I am unsure what "decisions made in the real world" has to do with my
observation that this real-world decision was a decision to invest time
and effort and money in one direction rather than another direction --
and the rejected other direction was the one that would make them users
of GCC who are affected by GCC decisions.


>> But your bespoke toolchain did not support the code which you need to
>> compile either. That's why you began hacking on it at all, to suit your
>> needs.
>>
>> So if neither GCC nor your bespoke toolchain support the code you need
>> to compile, and you must modify *something* to suit yourself, then it is
>> definitely possible to do it for GCC instead.
>>
>> I don't see what the welcome for making these modifications into the
>> default flagship experience for the entire free software ecosystem, has
>> to do with your being welcome to hack on GCC for your own personal use.
>>
>> Do you feel welcome by your proprietary vendor, who refuses to let you
>> touch it at all by withholding source code?
> 
> No, I do not.  I can not speak for my management.
> 
> But I also do not feel any welcome from a group of developers who are
> interested in breaking other code, some of which I have written for
> myself, and then religiously defend their decisions.
> 
> In short, I do not like being told what to do with my own code!


I do not consider that you are being told what to do with your code.
Your code is not being broken. You may have to update your Makefile to
add a flag that turns off a changed default, but that does not
constitute being told what to do with your code, only being told what to
do with GCC.


>> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
>> /usr/bin/python.
>>
>> ...
>>
>> No, the criteria for whether something constitutes a given programming
>> language are not "the file extension says so" or "the compiler name says
>> so".
>>
>> A programming language is defined by the syntax and meaning of that
>> programming language.
> 
> OK, and the Portable C Compiler from Bell Labs followed one such
> definition of its syntax and meaning.
> 
> ANSI and ISO simply define several such variants of the C language,
> collectively known as Standard C.  1st edition K&R defines another, and
> each compiler, in practice, defines its own.  Just like there are
> different varieties of English, or perhaps German.
> 
>> (If we were to replace this conversation with a definition of what
>> constitutes python, then as a scripted language, all files without file
>> extensions could be python scripts. And similarly, people play
>> interesting games with C files by naming them unconventional names and
>> passing -xc to the compiler. File extension autodetection isn't everything.)
> 
> This is pure pedantry.  My point is:
> 
>   If it looks like a duck, and quacks like a duck, then it is a duck.
> 
> or, IOW:
> 
>   If it looks like C, compiles in a C compiler, then it is C.


Very well then, (lots of) C++ is C.

But many people do in fact argue that missing function declarations do
not, in fact, look like C. It doesn't compile in a C compiler (using
-Werror) either. Some of the warnings under discussion in this thread
were never valid *anywhere*.


>> Well no, because if they are sufficiently dedicated to their existing
>> code to not have changed in over 30 years then they are writing c89 code
>> and passing -std=c89, and this is acceptable as far as GCC is concerned
>> and their code will still compile.
> 
> They are not writing ``C89'' code.  They are writing ``GNU99'', or perhaps
> ``GNU11'' code.


Some people like writing some code in one language version, and some
code in another language version, and doing so in the same file or
perhaps even the same function. Acknowledged. I would personally be
afraid to do that, it seems incredibly dangerous even if in the highly
specific case of implicit function declarations it happened to work.

Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being valid GNU99 or GNU11 code.

The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
make it a GNU extension. It compiles with a warning in c11 mode too,
does that make it a c11 extension? No it does not.


>> So they won't feel inclined to find some other compiler, and quite
>> frankly, if they were doing the right thing in accordance with the
>> standard way to use the language they prefer to use, then they probably
>> will not notice that GCC changed anything?
> 
> What gives you the right to dictate what the Right Thing is and what is
> not?


I am not dictating anything to you or anyone else in this paragraph,
though? All I said was that if one writes a c89 program and tells the
compiler that, then they will not even notice this entire discussion to
begin with.

What, precisely, have I dictated?

Have I dictated to you that a c89 program can be described to the
compiler by use of the -std=c89 flag? This seems to be a pretty standard
understanding, to me.


>> What guarantees of the future do you have for anything?
>> [...]
> 
> You are arguing to absurdity.


Correction: I am arguing by analogy that your statement: "what
guarantees that -Wno-implicit will not be removed in the future" is
arguing to absurdity.



>> I think that what-ifs aren't the most productive use of our time. The
>> current proposal provides for -std=c89 and similar, so the current
>> proposal does not cause current GCC users to be unable to use GCC after
>> the proposed change.
> 
> Perhaps you must try writing a program which strictly conforms to the
> Standard, since you seem to be asking everyone to write in such a way.
> 
> My point is that there is a very significant body of economically
> valuable code written in the dialect of C actually implemented by GCC,
> as it stands right now, just as there is a significant (albiet not so
> much) body of traditional C (K&R) code.
> 
> If GCC is no longer able to compile such code, it will attract the
> legitimate anger of its users.  And making users angry is not productive
> in any way.


Many people write strictly conforming program, and consider lack of
conformance to be a coding error that must be fixed. It seems like a
wise endeavor, frankly. I am not sure why you are challenging me to do
so as though you think that I will be incapable of it and therefore be
forced to concede that toggling the default diagnostic for very old code
is a bad idea.

However, it does appear that we are still stuck in confusion here,
because you think that GCC is no longer able to compile such code, when
in fact it is able to.


>> If a future proposal causes current GCC users to be unable to use GCC
>> after the future proposal is implemented, then, and only then, should we
>> worry about whether it will be possible to use GCC. Then, and only then,
>> will a threat to prevent doing so have actually materialized.
> 
> Parse error.


Maybe I was unclear, allow me to rephrase.

If a future proposal to GCC results in GCC becoming unable to compile
some code, then and only then should we worry about the existence of
such a proposal.

Since no such proposal has been made, it is a slippery slope fallacy to
argue that ***this*** proposal constitutes a threat to users' ability to
compile their code (even their implicit-function-declarations code).

I do not believe it is reasonable to:

- engage in tons of argumentation and insist that it's a bad move for
  GCC 14 to change a default and add a flag to get back the old default

by claiming that it would be bad for users if:

- GCC 16 deletes the flag for getting back the old default

If it is proposed to delete the flag for getting back the old default,
then and only then do people with old codebases have a valid complaint
that GCC is becoming unusable for their purposes.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> Please be serious, and please don't mock your opponents.  This is a
> serious discussion of a serious subject, not a Twitter post.


I responded with precisely the degree of seriousness as the statement I
responded to.

For the record, I believe both statements to have been serious. Not
necessarily correct, but serious.


> Back to the subject: the guarantees I would personally like to have is
> that the current GCC development team sees backward compatibility as
> an important goal, and will try not to break old programs without very
> good technical reasons.  At least in Emacs development, that is the
> consideration that is very high on our priority list when making
> development decisions.  It would be nice if GCC (and any other GNU
> project, for that matter) would do the same, because being able to
> upgrade important tools and packages without fear is something users
> value very much.  Take it from someone who uses GCC on various
> platforms since version 1.40.


This discussion thread is about having very good technical reasons -- as
explained multiple times, including instances where you agreed that the
technical reasons were good.

Furthermore, even despite those technical reasons, GCC is *still*
committed to not breaking those old programs anyway. GCC merely wants to
make those old programs have to be compiled in an "old-programs" mode.

Can you explain to me how you think this goal conflicts with your goal?


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Seems that the algorithm and I agree.  I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).

I believe:

  extern int foo ();

covers at least 50% of all C functions, since they are generally defined
to return int (as an error indication) with no narrow types in any
prototyped parameter list.  That's a reasonable enough guess.

> We can diagnose these without invoking expensive machinery, unlike
> mismatched declarations.

How so?  Remember that `extern int foo ()' declares a function with no
parameter specification returning int.

Thus, it could mean either:

  foo (a, b)
  char *a;
  long b;

or

  foo (x, y)
  double x;
  double y;

or perhaps even

  foo (va_alist)
  va_dcl

The function may even be defined with a prototyped parameter list, as
long as said parameter list does not contain any narrow types which are
subject to default argument promotions.

> I don't see why these not being diagnosed by default makes erroring on
> the far simpler implicit case not valuable (even if it leads to people
> just consciously inserting wrong declarations - that means they
> acknowledged it and made a poor decision).

All this will lead to is people making what you deem to be a ``poor''
decision.  Especially if the people who have to solve the build problems
are not the original author(s) of the program being built.

> They can be caught in multiple places when obvious, such as when not
> done explicitly.  These are two different errors.

An implicit function declaration is NOT an obvious error.  It simply may
be an error.  What is the error here?

a (b, c)
long c;
{
  return pokeaddr (c, b * FOO);
}

/* in another translation unit */

b ()
{
  a (1, 0L);
}

GCC is not a judge of other people's code, and shouldn't try to be one.

> I can't say.  I don't have memory of the traditional mode outside of
> cpp.

-traditional tried to make GCC a K&R compiler.  It wasn't completely
K&R, but it worked well enough for most cases.  There,

  - `extern' definitions take effect even outside the scope in which
    they are declared.
  - typeof, inline, signed, const and volatile are not recognized.
  - unsigned narrow types promote to unsigned int.
  - string constants are always writable.  (BTW, -fwritable-strings
    was also removed, so you can see why I'm sceptical about
    any commitment to `-fpermissive' if it is ever introduced.)
  - register allocation is not performed within functions that call
    setjmp.
  - bit-fields are always unsigned.
  - single precision floating point arithmetic is carried out in
    double precision.
  - __STDC__ is not defined.

> The changes proposed today, however, are a few bits of entropy
> relevant in a few places - the overhead is low.

Yet it's rather pointless, as I explained above.

> It's not, though.  That's why this is being conversed about.  Even
> highly diligent people miss these (and even not-so-diligent people like
> me do - I've had more of these found by me passing -flto than I did by
> remembering to use an extra four -Werror=... flags, and that, of course,
> misses the int(...) case - which is not a useful one, usually what I
> meant there was (void), but strict-prototypes are a story for another
> day or year).

I can't say I've seen any such errors myself.  Perhaps people should be
told to run lint instead, whose sole job is to prevent these errors from
happening?

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that this real-world decision was a decision to invest time
> and effort and money in one direction rather than another direction --
> and the rejected other direction was the one that would make them users
> of GCC who are affected by GCC decisions.

The point is, we chose not to modify GCC for various reasons, and the
changes being proposed here will cause more people to make this choice.

> I do not consider that you are being told what to do with your code.
> Your code is not being broken. You may have to update your Makefile to
                                                 ^^^^^^^^^^^^^^^^^^^^

My code is being broken.  There are thousands of Makefiles, Autoconf
files containing configure tests, and so on.

> add a flag that turns off a changed default, but that does not
> constitute being told what to do with your code, only being told what to
> do with GCC.

That's GCC trying to tell me what to do with my own code.

> Very well then, (lots of) C++ is C.
>
> But many people do in fact argue that missing function declarations do
> not, in fact, look like C. It doesn't compile in a C compiler (using
                                                     ^^^^^^^^^^

% cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31
% cc -Xs -Werror hello.c -o hello
% ./hello
hello world
the time is: 1683856188
% cat hello.c

struct timeval
{
  long tv_sec;
  long tv_usec;
};

main ()
{
  struct timeval tv;

  printf ("hello world\n");
  if (gettimeofday (&tv, 0L))
    exit (1);
  printf ("the time is: %ld\n", tv.tv_sec);
}

% 

> -Werror) either. Some of the warnings under discussion in this thread
> were never valid *anywhere*.

Really? Is that, or is that not, a C compiler?

> Some people like writing some code in one language version, and some
> code in another language version, and doing so in the same file or
> perhaps even the same function. Acknowledged. I would personally be
> afraid to do that, it seems incredibly dangerous even if in the highly
> specific case of implicit function declarations it happened to work.
>
> Because that's exactly what is going on here. Features that were valid
> C89 code are being used in a GNU99 or GNU11 code file, despite that
> ***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.

> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
> make it a GNU extension. It compiles with a warning in c11 mode too,
> does that make it a c11 extension? No it does not.

Except it does?  Since the compiler is defining behavior that is
otherwise undefined (i.e. the behavior of a program after a diagnostic
is emitted after encountering an erroneous construct), it is defining
an extension.

> I am not dictating anything to you or anyone else in this paragraph,
> though? All I said was that if one writes a c89 program and tells the
> compiler that, then they will not even notice this entire discussion to
> begin with.
>
> What, precisely, have I dictated?

That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.

> Have I dictated to you that a c89 program can be described to the
> compiler by use of the -std=c89 flag? This seems to be a pretty standard
> understanding, to me.

No, see above.

> Correction: I am arguing by analogy that your statement: "what
> guarantees that -Wno-implicit will not be removed in the future" is
> arguing to absurdity.

The reason I asked for such a guarantee was that two important options
were in fact removed by the GCC developers in the past: -traditional and
-fwritable-strings.  So there is not exactly a good track record of
keeping useful options around, after features are made into those
arguments.

> Many people write strictly conforming program, and consider lack of
> conformance to be a coding error that must be fixed. It seems like a
> wise endeavor, frankly. I am not sure why you are challenging me to do
> so as though you think that I will be incapable of it and therefore be
> forced to concede that toggling the default diagnostic for very old code
> is a bad idea.

Really? So how many programs work when int is 16, 36, or 40 bits wide?
How many programs work when signed char has trap representations?
How many programs when char not 8 bits?

How many programs assume pointers can be converted into an integer type
without any loss of information?  How many programs assume that
pointers have only one possible integer representation?  (think lookup
tables using pointers to objects as keys)

How many programs assume NULL is all-bits-zero?  IOW, that this
initialization makes sense:

struct foo
{
  void *ptr;
  int xxxxx;
};

...

struct foo foo;
memset (&foo, 0, sizeof foo);
if (foo.ptr != 0) /* here, 0 is a null pointer constant, NOT zero */

How many programs assume that arithmetic comparisons between pointers to
different objects are defined behavior?  (think anything that involves
sorting and comparing different objects, i.e. binary trees)

And how many programs written today even work at all when `int32_t' (and
similar types) are not defined in stdint.h?

How many programs use external identifiers that require more than six
(or thirty-two) significant characters, or case significance?

A strictly conforming program cannot make ANY of these assumptions:

  A strictly conforming program shall use only those features of the
  language and library specified in this International Standard.)  It
  shall not produce output dependent on any unspecified, undefined, or
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
  implementation-defined behavior, and shall not exceed any minimum
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and as a result, they are very rarely seen.

> However, it does appear that we are still stuck in confusion here,
> because you think that GCC is no longer able to compile such code, when
> in fact it is able to.

It won't, not by default.

> Maybe I was unclear, allow me to rephrase.
>
> If a future proposal to GCC results in GCC becoming unable to compile
> some code, then and only then should we worry about the existence of
> such a proposal.
>
> Since no such proposal has been made, it is a slippery slope fallacy to
> argue that ***this*** proposal constitutes a threat to users' ability to
> compile their code (even their implicit-function-declarations code).
>
> I do not believe it is reasonable to:
>
> - engage in tons of argumentation and insist that it's a bad move for
>   GCC 14 to change a default and add a flag to get back the old default
>
> by claiming that it would be bad for users if:
>
> - GCC 16 deletes the flag for getting back the old default

I'm sorry, but this is what people have seen repeatedly happen over the
years.  Thus,

> If it is proposed to delete the flag for getting back the old default,
> then and only then do people with old codebases have a valid complaint
> that GCC is becoming unusable for their purposes.

Being sceptical about the future is perfectly reasonable.

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Indeed they should be - but warning vs. error holds significance.  A
> beginner is much less likely to be writing clever code that allegedly
> uses these features properly than to be building new code, and simply
> having made an error that they do not want and will suffer through
> confused.

Most programs already paste a chunk of Autoconf into their configure.ins
which turns on more diagnostics if it looks like the program is being
built by a developer.  i.e. from Emacs:

AC_ARG_ENABLE([gcc-warnings],
  [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
                  [control generation of GCC warnings.  The TYPE 'yes'
		   means to fail if any warnings are issued; 'warn-only'
		   means issue warnings without failing (default for
		   developer builds); 'no' means disable warnings
		   (default for non-developer builds).])],
  [case $enableval in
     yes|no|warn-only) ;;
     *)      AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
   esac
   gl_gcc_warnings=$enableval],
  [# By default, use 'warn-only' if it looks like the invoker of 'configure'
   # is a developer as opposed to a builder.  This is most likely true
   # if GCC is recent enough and there is a .git directory or file;
   # however, if there is also a .tarball-version file it is probably
   # just a release imported into Git for patch management.
   gl_gcc_warnings=no
   if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
      # Clang typically identifies itself as GCC 4.2 or something similar
      # even if it is recent enough to accept the warnings we enable.
      AS_IF([test "$emacs_cv_clang" = yes],
         [gl_gcc_warnings=warn-only],
         [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
   fi])

So this is really not a problem.

> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

Until `-fpermissive' goes the way of `-traditional',
`-fwritable-strings'.

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?

Have you actually seen anyone make this mistake?

> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
>
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.
>
> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

I'd expect a question from the newbie, directed at a web search engine.

> Hell, I've seen professors do it, and for a simple reason: they knew how
> to write code, not how to use a compiler.  That's a big gap.
>
> The beginner here can't adapt - they don't know what -Wall means, they
> just pass it because they were told to do it (if they're lucky!).

If this is really such a bad problem, then how about clarifying the
error message?

> At the same time, they lose out on what is, IMO, one of the most useful
> pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
> it by default.. we do).  It provides effective bug detection, when the
> code compiles right.  It regularly spots bugs that haven't happened yet
> for me.
>
> (and same goes for all the other useful analysis the toolchain can do
> when it has sufficient information to generate correct code, or more;
> some of which can't reasonably be a default)
>
> (on a related note, IMO it's a shame that the toolchain hides so many
> possibilities behind 'cult knowledge', depths of many manuals and bad
> defaults)

_FORTIFY_SOURCE is not really important enough to be considered here.
It's not even available everywhere.

> This sample is subject to selection bias.  My testing targets mostly
> more modern codebases that have long fixed these errors (if they have
> active maintainers), and exclusively Free Software, so I expect that the
> likelyhood that you'll need to run `export CC='gcc -fpermissive'
> CXX='g++ -fpermissive'` goes up the more you move towards old or more
> corporate codebases, but, for a veteran, this is no cost at all.
>
> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K&R-esque practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

There's bash, which still tries to work on later 4.3BSDs (AFAIK), while
also building with just `gcc'.

> As an anecdote, just recently I had to fix some code written for i686
> CPUs, presumably for GCC 4.something or less, because the GCC I insist
> on using (which is 13 and has been since 13.0 went into feature-freeze)
> has started using more than the GPRs on that machine (which lead to hard
> to debug crashes because said codebase does not enable the requisite CPU
> extensions, or handle the requisite registers properly).  I think this
> fits within the definition of 'worked yesterday, broke today'.  Should
> that change be reverted?  Replacing it with -mmore-than-gprs would make
> GCC more compatible with this old code.
>
> I don't think so.
>
> This is a sensitive codebase, and not just because it's written poorly,
> but because it's a touchy thing it's implementing, any change in
> compiler requires reverification.  The manifestation here has *no*
> significance.

And the problematic part of the code in question is implementing
something like swapcontext in assembler, correct?  That's a far cry from
breaking C code, which does have clearly defined (albeit not exactly
intuitive) semantics.

> ... speaking of that, if one builds their codebase without -std=..,
> they're risking more than just optimization changes breaking code that
> relies on bad assumptions, they're also risking a change in language
> semantics..

The Standards committee does have a reasonable track record of keeping
backwards compatibility, since they prioritize existing practice and the
existing body of C code.  So I'm not too worried about that.

> With all that to consider, is it *really* a significant cost to add
> -fpermissive?

Yes, in case it goes away.

> Would that cost not be massively overshadowed by the cost
> of a compiler change?  It feels like it's a footnote compared to
> checking whether added optimizations go against invalid assumptions
> (which is, by the way, also rectified by adding more hard and easy
> to see errors).
>
> I expect no change in behavior from those that maintain these old
> codebases, they know what they're doing, and they have bigger fish to
> fry - however, I expect that this change will result in:
>
> - A better reputation for GCC and the GCC project (by showing that we do
>   care for code correctness),

A compiler should care about the correctness of its own code, not that
of others.

> - More new code being less error prone (by merit of simple errors being
>   detected more often),

As I said, making such things errors will simply result in people
inserting `extern' declarations everywhere, which may or may not be
wrong.  I've seen this happen before with my own eyes.

> - Less 'cult knowledge' in the garden path,

I guess search engines, and better written diagnostic messages, would be
enough to accomplish that?

> - More responsible beginners, and
> - Fewer people being able to effectively paint GNU and/or C/++ as the
>   backwards crowd using a error-prone technique of yesteryear.

This never worked in GNU C++, right?

> (and yes, optics matter)
>
> Builds break.  Builds breaking cleanly is a treat compared to the usual
> breakage.  At least this breaks the few that do break with a positive
> outcome.

Builds shouldn't break, and the ``usual treat'' should also not
happen...

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.
>
> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
>
> Can you explain to me how you think this goal conflicts with your goal?

Because now people will have to go through dozens and dozens of
Makefiles, configure.in, *.m4, just because GCC made a decision that
results in everyone inserting:

  extern int foo ();

above what used to be implicit function declarations?

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>
> The argument is that on newer values for -std (such as the one GCC
> defaults to if no -std is specified), GCC should adapt its diagnostics
> better for the std in question. These newer -stds should stop issuing a
> warning diagnostic, and begin issuing an error diagnostic instead.
>
> The latter group most certainly does have somewhere to go other than
> proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
> -fpermissive or -fold-code or whatever the case may be).
>
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?

Yes.

> So what is the moral of this story? To avoid repeating the story of
> -traditional, and instead make sure that users of -std=c89 always have a
                                                             ^^^^^^
> flag they can use to indicate they are writing old c89 code?
>
> If so, then as far as I can tell, that was the original plan? The flag
> already exists, even. And the original proposal was to provide another
> flag that doesn't even restrict you to c89.

And what will guarantee this ``always'' always remains true?

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> And I would not want to see that happen either, nor do I think Florian
> would, or many of the other participants in this thread.
>
> Indeed, for some projects, where it's hopeless^Wlots of work,
> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>
> But most things are easy to fix.
>
> Our interest is purely in making the default stricter for better UX,
> reducing the net amount of these bugs in the wild, and avoiding
> regressions when we fix these problems. Trying to remove C89 entirely
> would, if nothing else, be needlessly antagonistic, but some of the
> replies seem to act as if we have.

But programs are not using c89 or gnu89, right? They are using gnu99 and
gnu11.

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu <luangruo@yahoo.com> writes:

> Sam James <sam@gentoo.org> writes:
>
>> And I would not want to see that happen either, nor do I think Florian
>> would, or many of the other participants in this thread.
>>
>> Indeed, for some projects, where it's hopeless^Wlots of work,
>> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>>
>> But most things are easy to fix.
>>
>> Our interest is purely in making the default stricter for better UX,
>> reducing the net amount of these bugs in the wild, and avoiding
>> regressions when we fix these problems. Trying to remove C89 entirely
>> would, if nothing else, be needlessly antagonistic, but some of the
>> replies seem to act as if we have.
>
> But programs are not using c89 or gnu89, right? They are using gnu99 and
> gnu11.

They're using > c89/gnu89 often because defaults have changed (a point
others have raised, including Arsen and Eli Schwartz) even though they
weren't intended to be compiled with newer C.

A fair amount of other projects do explicitly ask for either c99/gnu99
or c11/gnu11 and if they're doing that, they shouldn't be getting
something which was removed from the C standard. But if they really want
it, they can either downgrade to C89 (rather drastic), or set the
proposed -fpermissive.

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

Re: More C type errors by default for GCC 14

[Jason Merrill]

On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc <gcc@gcc.gnu.org> wrote:
>
> Eli Schwartz <eschwartz93@gmail.com> writes:
>
> > This discussion thread is about having very good technical reasons -- as
> > explained multiple times, including instances where you agreed that the
> > technical reasons were good.
> >
> > Furthermore, even despite those technical reasons, GCC is *still*
> > committed to not breaking those old programs anyway. GCC merely wants to
> > make those old programs have to be compiled in an "old-programs" mode.
> >
> > Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4

You shouldn't have to change any of those, just configure with CC="gcc
-fwhatever".

Jason

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> Eli Schwartz <eschwartz93@gmail.com> writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

I've seen 0 instances of this. All of the fixes we've made have been
proper and all the fixes I've seen when I report but don't fix an
issue have been proper.

We wouldn't have proposed this if that was the case. Maybe you should
take your case to the C committee that removed the feature in the first
place and tell them to reinstate it because of.. ^

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

Re: More C type errors by default for GCC 14

[Sam James]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

> Eli Schwartz <eschwartz93@gmail.com> writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

In addition to Jason's point about just setting CC, I'd also expect
there to be a few centralised places where the flags are set in most
projects anyway.

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

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 10:08 PM, Po Lu wrote:
>> I do not consider that you are being told what to do with your code.
>> Your code is not being broken. You may have to update your Makefile to
>                                                  ^^^^^^^^^^^^^^^^^^^^
> 
> My code is being broken.  There are thousands of Makefiles, Autoconf
> files containing configure tests, and so on.


There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update your Makefile, but that is no big deal.

It's still no big deal, no matter how much you dramatize the intensity
of adding a flag to your Makefiles.


>> add a flag that turns off a changed default, but that does not
>> constitute being told what to do with your code, only being told what to
>> do with GCC.
> 
> That's GCC trying to tell me what to do with my own code.


So you concede that GCC is not telling you, only trying and failing to
tell you?

Great, so what's the problem? If GCC can't actually enforce it, and even
goes out of its way to offer you options to ignore what it's telling you
to do, then maybe...

... it's not telling you what to do with your code, only suggesting what
to do?

So ignore the suggestion.

I'm not sure what this semantics game here is trying to say. Is it
ethically and morally wrong for GCC to try to tell you what to do with
your code? Is it undignifying to have a mere machine go and lecture you,
a real human being with a consciousness and free will, what to do?

Because if that's what this is about then I think you are taking this
inanimate object way too personally.

If not, then I am simply entirely unsure what your objection is to being
"told".


>> Because that's exactly what is going on here. Features that were valid
>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>> ***not*** being valid GNU99 or GNU11 code.
> 
> How GCC currently behaves defines what is valid GNU C.


No. Absolutely positively 100% no under any circumstances whatsoever no.

This has been explained multiple times by the GCC developers. e.g.
search for references to accepts-invalid.

"""
They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
"""

You cannot, and are not permitted, to define "how GCC currently behaves"
as "defines what is valid GNU C". No one agrees with your analysis. Most
importantly, GCC does not agree with your analysis.

It's a wild, wild, wild claim to begin with. You are arguing that any
bug, ANY bug whatsoever, which qualifies for the title "how GCC
currently behaves" because if a bug is currently present, then GCC
currently behaves in a buggy manner...

... any such bug is, ***because*** GCC currently does it, now part of
the documentation on "GNU C", a language dialect with documentation.

Can you show me where on
https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
documentation states that "C Extensions include anything that GCC
currently does, no matter what, no matter how documented or undocumented"?


>> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
>> make it a GNU extension. It compiles with a warning in c11 mode too,
>> does that make it a c11 extension? No it does not.
> 
> Except it does?  Since the compiler is defining behavior that is
> otherwise undefined (i.e. the behavior of a program after a diagnostic
> is emitted after encountering an erroneous construct), it is defining
> an extension.


The concept of a language extension has bulletproof meaning. You cannot
get around it, redefine it, pretend that something is when it isn't, or
otherwise disagree with this bulletproof meaning.

The compiler defines an extension by writing about it in its
documentation on "GNU C extensions".

Anything else you have to say on the topic is automatically wrong.

Language has meaning. *Words* have meaning. The word "extension" has a
very specific meaning in the GCC documentation. You can read all about
it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html


>> I am not dictating anything to you or anyone else in this paragraph,
>> though? All I said was that if one writes a c89 program and tells the
>> compiler that, then they will not even notice this entire discussion to
>> begin with.
>>
>> What, precisely, have I dictated?
> 
> That people who are writing GNU C code should be forced to rewrite their
> code in ANSI C, in order to make use of GNU C extensions to the 1999
> Standard.


I did not dictate that you have to rewrite your code. You are replying
to something that has no relationship whatsoever to any form of
instruction, telling, or even ***advice***, and calling it dictation. I
reiterate: this paragraph was me ***observing*** a fact. That fact is
that if someone happens to do X, then they will not be affected by this
discussion.

(X is, in this case, "someone wrote ANSI C code and also chose to use a
flag telling the compiler that it is ANSI C".)


But, furthermore, I would like to now clarify something anyway.

You are not writing GNU C code, you never have been. GNU C code is
defined by the documentation for GNU C:
https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

You may take this as me dictating to you that you are not to call this
code "GNU C".



> The reason I asked for such a guarantee was that two important options
> were in fact removed by the GCC developers in the past: -traditional and
> -fwritable-strings.  So there is not exactly a good track record of
> keeping useful options around, after features are made into those
> arguments.

[...]

>> by claiming that it would be bad for users if:
>>
>> - GCC 16 deletes the flag for getting back the old default
> 
> I'm sorry, but this is what people have seen repeatedly happen over the
> years.  Thus,
> 
>> If it is proposed to delete the flag for getting back the old default,
>> then and only then do people with old codebases have a valid complaint
>> that GCC is becoming unusable for their purposes.
> 
> Being sceptical about the future is perfectly reasonable.


My opinion on this is (still) that if your argument is that you don't
want -fpermissive or -std=c89 to be removed, you are more than welcome
to be skeptical about that (either one or both), but I don't see why
that is on topic for the question of whether things should be moved to
flags such as those while they do exist.

If they want to remove -fpermissive, or -std=c89, out of an
unwillingness to provide compilers capable of being instructed to accept
and compile your coding style, then they will do so regardless of this
conversation.

We might as well assume that the GCC developers are honest and truthful
people, otherwise it is *definitely* a waste of time asking them about
this change in the first place.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/11/23 10:39 PM, Po Lu wrote:
>> If so, then as far as I can tell, that was the original plan? The flag
>> already exists, even. And the original proposal was to provide another
>> flag that doesn't even restrict you to c89.
> 
> And what will guarantee this ``always'' always remains true?


Nothing. The future has not happened yet, so it cannot be guaranteed. As
I said in a previous reply, the earth may be struck by a meteor and
annihilate all life on earth. I cannot guarantee for you that such an
event will never happen.

All I can say is that I think it is pretty unlikely and not worth
worrying about.

And similarly, I can say about your concern, that I think it is pretty
unlikely.

If you will not be satisfied by anything less than a "guarantee" then I
don't know what to say. Maybe hire a lawyer and draw up a contract that
you convince the GCC developers to sign, saying that they are not
legally allowed to remove the flag? Would this make you happy?


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> They're using > c89/gnu89 often because defaults have changed (a point
> others have raised, including Arsen and Eli Schwartz) even though they
> weren't intended to be compiled with newer C.
>
> A fair amount of other projects do explicitly ask for either c99/gnu99
> or c11/gnu11 and if they're doing that, they shouldn't be getting
> something which was removed from the C standard. But if they really want
> it, they can either downgrade to C89 (rather drastic), or set the
> proposed -fpermissive.

Too much trouble.

Let me tell you what will actually happen: people will never do what you
want them to.  Instead, they will simply write:

  extern int foo ();

above the new errors.  As a result, you will not have really
accomplished anything other than making a lot of users angry.  The
declarations will continue to be as correct as they have always been.

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> There are ***not*** thousands of Makefiles that have this issue. But if
> there were, then Makefiles are very easy to update, and only have to be
> updated once per project, not thousands of times. So this is fine. You
> may have to update your Makefile, but that is no big deal.
>
> It's still no big deal, no matter how much you dramatize the intensity
> of adding a flag to your Makefiles.

It's extra work.  Why don't I just write:

  extern int foo ();

above each of the new errors?
That is just about what anyone will do when confronted by these new
errors.  As a result, you have not ensured that any declarations are
correct, but instead you have annoyed a lot of people and lulled
yourself into a false sense of safety.

> So you concede that GCC is not telling you, only trying and failing to
> tell you?

I concede that you're playing with words.

> Great, so what's the problem? If GCC can't actually enforce it, and even
> goes out of its way to offer you options to ignore what it's telling you
> to do, then maybe...
>
> ... it's not telling you what to do with your code, only suggesting what
> to do?
>
> So ignore the suggestion.

Which is made annoying, especially when there is absolutely NO guarantee
being made that the new option will stay.

> I'm not sure what this semantics game here is trying to say. Is it
> ethically and morally wrong for GCC to try to tell you what to do with
> your code? Is it undignifying to have a mere machine go and lecture you,
> a real human being with a consciousness and free will, what to do?
>
> Because if that's what this is about then I think you are taking this
> inanimate object way too personally.
>
> If not, then I am simply entirely unsure what your objection is to being
> "told".
>
>
>>> Because that's exactly what is going on here. Features that were valid
>>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>>> ***not*** being valid GNU99 or GNU11 code.
>> 
>> How GCC currently behaves defines what is valid GNU C.
>
>
> No. Absolutely positively 100% no under any circumstances whatsoever no.
>
> This has been explained multiple times by the GCC developers. e.g.
> search for references to accepts-invalid.
>
> """
> They are bugs where compiler accepts something that isn't valid in
> the selected language nor considered valid extension.
> So, after the fix we reject something that has been accepted before.
>
> In the last few years (checked what was fixed in 10/11/12/13 releases so
> far), we've fixed 12 such bugs explicitly marked that way:
> """

The Standard states that each conforming implementation must be
accompanied by a document which documents each and every extension.

This document is the GCC manual, which makes reference (not too clearly,
however, which should be fixed) to both implicit int and implicit
function declarations, which are allowed in C99 and later dialects of C.

These constructs are not bugs.  These constructs explicitly defined by
GNU C; since a diagnostic is issued, GNU C's implementation also
conforms to the Standard.

> You cannot, and are not permitted, to define "how GCC currently behaves"
> as "defines what is valid GNU C". No one agrees with your analysis. Most
                                    ^^^^^^

I'm not a person?

> importantly, GCC does not agree with your analysis.

For some definition of GCC, which is apparently you.

> It's a wild, wild, wild claim to begin with. You are arguing that any
> bug, ANY bug whatsoever, which qualifies for the title "how GCC
> currently behaves" because if a bug is currently present, then GCC
> currently behaves in a buggy manner...
>
> ... any such bug is, ***because*** GCC currently does it, now part of
> the documentation on "GNU C", a language dialect with documentation.
>
> Can you show me where on
> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
> documentation states that "C Extensions include anything that GCC
> currently does, no matter what, no matter how documented or undocumented"?

I see:

`-Wno-implicit-int (C and Objective-C only)'
     This option controls warnings when a declaration does not specify a
     type.  This warning is enabled by default in C99 and later dialects
     of C, and also by `-Wall'.

`-Wno-implicit-function-declaration (C and Objective-C only)'
     This option controls warnings when a function is used before being
     declared.  This warning is enabled by default in C99 and later
     dialects of C, and also by `-Wall'.  The warning is made into an
     error by `-pedantic-errors'.

> The concept of a language extension has bulletproof meaning. You cannot
> get around it, redefine it, pretend that something is when it isn't, or
> otherwise disagree with this bulletproof meaning.

The concept of a ``language extension'' is not defined anywhere.
Instead, there are three kinds of behavior not precisely specified by
the Standard:

  - undefined behavior, the behavior upon use of an erroneous construct
    for which the Standard imposes no requirements whatsoever.

  - unspecified behavior, where upon the use of a construct for which
    the Standard imposes two or more possible behaviors, and leaves the
    selected behavior unspecified.

  - implementation-defined behavior, unspecified behavior where each
    implementation documents how the choice is made, and is required to
    document that choice.

If the translator precisely defines either undefined behavior (in this
case, erroneous syntax) or unspecified behavior, then that definition is
commonly considered to be an extension of that translator.  Nothing
gcc.info says will change that.

> The compiler defines an extension by writing about it in its
> documentation on "GNU C extensions".
>
> Anything else you have to say on the topic is automatically wrong.
>
> Language has meaning. *Words* have meaning. The word "extension" has a
> very specific meaning in the GCC documentation. You can read all about
> it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

GNU C documentation does not decide what is an extension and what is
not.  In any case, if (gcc)C Extensions does not mention extensions
currently implemented by GCC, then that is a bug in the documentation,
is it not?  Documentation is supposed to reflect what the program being
documented does, not the other way around.  Like the Standard says:

  An implementation shall be accompanied by a document that defines all
  implementation- defined and locale-specific characteristics and all
  extensions.

> I did not dictate that you have to rewrite your code. You are replying
> to something that has no relationship whatsoever to any form of
> instruction, telling, or even ***advice***, and calling it dictation. I
> reiterate: this paragraph was me ***observing*** a fact. That fact is
> that if someone happens to do X, then they will not be affected by this
> discussion.
>
> (X is, in this case, "someone wrote ANSI C code and also chose to use a
> flag telling the compiler that it is ANSI C".)
>
>
> But, furthermore, I would like to now clarify something anyway.
>
> You are not writing GNU C code, you never have been. GNU C code is
> defined by the documentation for GNU C:
> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
>
> You may take this as me dictating to you that you are not to call this
> code "GNU C".

Really?  Then why is __GNUC__ defined, and why does it compile with
`gcc'?

> My opinion on this is (still) that if your argument is that you don't
> want -fpermissive or -std=c89 to be removed, you are more than welcome
> to be skeptical about that (either one or both), but I don't see why
> that is on topic for the question of whether things should be moved to
> flags such as those while they do exist.
>
> If they want to remove -fpermissive, or -std=c89, out of an
> unwillingness to provide compilers capable of being instructed to accept
> and compile your coding style, then they will do so regardless of this
> conversation.
>
> We might as well assume that the GCC developers are honest and truthful
> people, otherwise it is *definitely* a waste of time asking them about
> this change in the first place.

How honest and truthful they are does not reflect whether or not the
proposed new option will be kept around.  In fact, I observe that none
of them have committed to supporting such an option indefinitely.

Re: More C type errors by default for GCC 14

[Po Lu]

Jason Merrill <jason@redhat.com> writes:

> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

If it were so simple...

Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
`cc', to build programs which are run on the build machine.

These programs are intended to be as portable as possible (naturally,
since Autoconf does not configure for the build machine).  As a result,
they are typically written in the subset of ANSI C that will compile
with almost any C compiler, which is exactly what will cause problems
with GCC's proposed new defaults.

Re: More C type errors by default for GCC 14

[Po Lu]

Sam James <sam@gentoo.org> writes:

> I've seen 0 instances of this. All of the fixes we've made have been
> proper and all the fixes I've seen when I report but don't fix an
> issue have been proper.

And how many percent of all C code in the world is that?  1%?
Maintained free software, popular enough to be packaged by GNU/Linux
distributions such as Gentoo, is only the tip of the iceberg here.

> We wouldn't have proposed this if that was the case. Maybe you should
> take your case to the C committee that removed the feature in the first
> place and tell them to reinstate it because of.. ^

C2X opens a whole new can of worms.  The current release of bash won't
even build with a C2X compiler.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Thu, 11 May 2023 18:30:20 -0400
> Cc: luangruo@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz <eschwartz93@gmail.com>
> 
> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
> > 
> > He is telling you that removing support for these old features, you
> > draw users away from GCC and towards proprietary compilers.
> > 
> > One of the arguments in this thread _for_ dropping that support was
> > that by not rejecting those old programs, GCC draws some users away
> > from GCC.  He is telling you that this change will, perhaps, draw some
> > people to GCC, but will draw others away from GCC.  The difference is
> > that the former group will start using Clang, which is still free
> > software (at least some of its versions), whereas the latter group has
> > nowhere to go but to proprietary compilers.  So the FOSS community
> > will have suffered a net loss.  Something to consider, I think.
> 
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?
> 
> So what is the moral of this story?

See above: that repeating the story of -traditional could result in
net loss for the FOSS movement.

> To avoid repeating the story of -traditional, and instead make sure
> that users of -std=c89 always have a flag they can use to indicate
> they are writing old c89 code?

No, the moral is not to introduce breaking behavior without very good
technical reasons.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Thu, 11 May 2023 18:43:32 -0400
> Cc: luangruo@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz <eschwartz93@gmail.com>
> 
> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> 
> > Back to the subject: the guarantees I would personally like to have is
> > that the current GCC development team sees backward compatibility as
> > an important goal, and will try not to break old programs without very
> > good technical reasons.  At least in Emacs development, that is the
> > consideration that is very high on our priority list when making
> > development decisions.  It would be nice if GCC (and any other GNU
> > project, for that matter) would do the same, because being able to
> > upgrade important tools and packages without fear is something users
> > value very much.  Take it from someone who uses GCC on various
> > platforms since version 1.40.
> 
> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.

They are not technical, no.  Leaving the current behavior does not
technically hamper GCC and its users in any way -- GCC can still
compile the same programs, including those with modern std= values, as
it did before, and no false warnings or errors are caused when
compiling programs written in valid standard C.

The reasons are basically PR: better reputation for GCC etc.  Maybe
even fashion: Clang does that, so how come we don't?

> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
> 
> Can you explain to me how you think this goal conflicts with your goal?

I already did, in previous messages, where I described what we all are
familiar with: the plight of a maintainer of a large software system
whose build suddenly breaks, and the difficulty in understanding which
part of the system's upgrade caused that.  I'd rather not repeat that:
there are already too many repetitions here that make the discussion
harder to follow.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Fri, 12 May 2023, 07:02 Po Lu via Gcc, <gcc@gcc.gnu.org> wrote:

> Jason Merrill <jason@redhat.com> writes:
>
> > You shouldn't have to change any of those, just configure with CC="gcc
> > -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.
>
> These programs are intended to be as portable as possible (naturally,
> since Autoconf does not configure for the build machine).  As a result,
> they are typically written in the subset of ANSI C that will compile
> with almost any C compiler, which is exactly what will cause problems
> with GCC's proposed new defaults.
>

Then they should not use implicit int and implicit function declarations.

You've made your opinion clear. It has been noted.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jason Merrill <jason@redhat.com>
> Date: Thu, 11 May 2023 22:55:07 -0400
> Cc: Eli Schwartz <eschwartz93@gmail.com>, Eli Zaretskii <eliz@gnu.org>, gcc@gcc.gnu.org
> 
> > Because now people will have to go through dozens and dozens of
> > Makefiles, configure.in, *.m4
> 
> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

That doesn't always work.  Whether it works or not depends on how the
Makefile's are written, whether libtool is or isn't being used, etc.

So yes, it will work in some, perhaps many, cases, but not in all of
them.

Moreover, the main problem with such a change is discovering that the
build broke because of different GCC defaults, and that adding
"-fpermissive" is all that's needed to pacify GCC.  I already tried to
explain why this is nowhere as simple in real life as some people here
seem to assume.  The aggravation and frustration caused by that
process of discovery is the main downside of this proposal, and I hope
it will be considered very seriously when making the decision.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Thu, 11 May 2023 23:07:55 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> 
> > Being sceptical about the future is perfectly reasonable.
> 
> My opinion on this is (still) that if your argument is that you don't
> want -fpermissive or -std=c89 to be removed, you are more than welcome
> to be skeptical about that (either one or both), but I don't see why
> that is on topic for the question of whether things should be moved to
> flags such as those while they do exist.

It is on topic because there doesn't seem to be anything in the
arguments brought up for this current proposal that couldn't be
brought up in favor of removing -fpermissive.  There are no guiding
principles being uttered which allow the current proposal, but will
disallow the removal of -fpermissive.  The same "let's be more popular
and forthcoming to newbies, and more like Clang" PR-style stuff can
justify both.

> We might as well assume that the GCC developers are honest and truthful
> people, otherwise it is *definitely* a waste of time asking them about
> this change in the first place.

This is not about honesty.  No one is questioning the honesty of GCC
developers.  What is being questioned are the overriding principles
that should be applied when backward-incompatible changes are
proposed.  Are there such principles in GCC development, and if there
are, where are they documented?  Or are such discussions just some
ad-hoc disputes, and the results are determined by which party is at
that time more vocal?

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc, <gcc@gcc.gnu.org> wrote:

> > Date: Thu, 11 May 2023 23:07:55 -0400
> > Cc: gcc@gcc.gnu.org
> > From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> >
> > > Being sceptical about the future is perfectly reasonable.
> >
> > My opinion on this is (still) that if your argument is that you don't
> > want -fpermissive or -std=c89 to be removed, you are more than welcome
> > to be skeptical about that (either one or both), but I don't see why
> > that is on topic for the question of whether things should be moved to
> > flags such as those while they do exist.
>
> It is on topic because there doesn't seem to be anything in the
> arguments brought up for this current proposal that couldn't be
> brought up in favor of removing -fpermissive.  There are no guiding
> principles being uttered which allow the current proposal, but will
> disallow the removal of -fpermissive.



"Let's change a default and add an option to get the old default" is really
not the disaster you're making it out to be. You're becoming a laughing
stock at this point.


The same "let's be more popular
> and forthcoming to newbies, and more like Clang" PR-style stuff can
> justify both.
>


It's not about popularity. If that's your takeaway then you're not paying
attention, whatever you claim about reading everything in the thread. It's
about helping people write correct code, first time, without some of the
avoidable traps that C presents.

The C ecosystem has a shockingly bad reputation when it comes to security
and "just don't write bugs" is naive and ineffective. Maybe you're good
enough for that to work, but then you should also be able to cope with a
change in defaults.

It's time for some defaults to change so that modern C is preferred, and
"implicit everything, hope the programmer got it right" requires explicit
action, *but it's still possible to do* for the 1970s nostalgia fans.

If you want to believe that's the start of a slippery slope, that's your
choice. The nostalgia club can always fork gcc if necessary, that's one of
the great things about free software.


> > We might as well assume that the GCC developers are honest and truthful
> > people, otherwise it is *definitely* a waste of time asking them about
> > this change in the first place.
>
> This is not about honesty.  No one is questioning the honesty of GCC
> developers.  What is being questioned are the overriding principles
> that should be applied when backward-incompatible changes are
> proposed.  Are there such principles in GCC development, and if there
> are, where are they documented?  Or are such discussions just some
> ad-hoc disputes, and the results are determined by which party is at
> that time more vocal?
>

GCC has always taken backwards compatibility seriously. That doesn't mean
it is the prime directive and can never be violated, but it's absolutely
always considered. In this case, changing the default seems appropriate to
many people, including those who actually maintain gcc and deal with the
consequences of the current defaults.

Do you have anything new to add other than repeating the same arguments?
We've heard them now, thanks.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 21:25:53 +0200
> 
> >> This seems like a good route to me - it facilitates both veterans
> >> maintaining code and beginners just learning how to write C.
> >
> > No, it prefers beginners (which already have the warnings, unless they
> > deliberately turn them off) to veterans who know what they are doing,
> > and can live with those warnings.
> 
> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

Let's keep in mind that veterans are much more likely to have to deal
with very large programs than newbies, and so dealing with breakage
for them is much harder than doing that in a toy program.  Thus, the
proposal does "pressure the old very much".

> > The right balance is exactly what we have now: emitting warnings
> > without breaking builds.
> 
> I disagree - I think breaking builds here (remember, it takes 13 bytes
> to fix them) is a much lower weight than the other case being shot in
> the foot for an easily detectable and treatable error being made easily
> missable instead, so I reckon the scale is tipped heavily towards the
> veterans.

I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration.  The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.  You are talking
only about what follows these two discovery processes, and that misses
the main disadvantage of this proposal (an in fact almost any breaking
proposal).

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?
> 
> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
> 
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.

That's perfectly okay: the beginner made a mistake of ignoring a
warning, and now he or she will need to pay for that mistake.

But why should someone else pay, and pay dearly, for the mistakes of
such newbies?  That is simply unfair.  The payment should be on the
one who made the mistake.

> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

They don't need to.  They just need to fix their bad code, that's all.

> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K&R-esque practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

If the program built okay till now, they might not know.

> As an anecdote, just recently I had to fix some code written for i686
> CPUs, presumably for GCC 4.something or less, because the GCC I insist
> on using (which is 13 and has been since 13.0 went into feature-freeze)
> has started using more than the GPRs on that machine (which lead to hard
> to debug crashes because said codebase does not enable the requisite CPU
> extensions, or handle the requisite registers properly).  I think this
> fits within the definition of 'worked yesterday, broke today'.

But it broke for a valid technical reasons: GCC was improved by
supporting more registers, and thus it now emits better code.  This
kind of reason is perfectly legitimate for breaking some old and
borderline-invalid programs, especially if GCC was emitting warnings
for those programs in past releases.

But the change discussed here is not like that.

> With all that to consider, is it *really* a significant cost to add
> -fpermissive?

See above (and my earlier message): the significant cost is to
discover the root cause of the problem, and that -fpermissive is the
solution.  The rest might be relatively easier, at least in some
projects.

> I expect no change in behavior from those that maintain these old
> codebases, they know what they're doing, and they have bigger fish to
> fry - however, I expect that this change will result in:
> 
> - A better reputation for GCC and the GCC project (by showing that we do
>   care for code correctness),
> - More new code being less error prone (by merit of simple errors being
>   detected more often),
> - Less 'cult knowledge' in the garden path,
> - More responsible beginners, and
> - Fewer people being able to effectively paint GNU and/or C/++ as the
>   backwards crowd using a error-prone technique of yesteryear.

These are not technical reasons in my book, they are PR stuff.
Breaking code that was building previously based on such reasons
should be unacceptable in any project that respects its users.

> Builds break.

Yes, and cars crash every day.  But we still consider car crashes to
be undesirable, and take measures to minimize that.  IOW, there's no
reason to be fatalistic about build breakage; we should instead
proactively try to minimize that.

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > From: Arsen Arsenović <arsen@aarsen.me>
> > Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> > Date: Thu, 11 May 2023 21:25:53 +0200
> > 
> > >> This seems like a good route to me - it facilitates both veterans
> > >> maintaining code and beginners just learning how to write C.
> > >
> > > No, it prefers beginners (which already have the warnings, unless they
> > > deliberately turn them off) to veterans who know what they are doing,
> > > and can live with those warnings.
> > 
> > Indeed.  I said facilitates, not treats equally.  I think the veterans
> > here won't lose much by having to pass -fpermissive, and I think that's
> > a worthwhile sacrifice to make, to nurture the new without pressuring
> > the old very much.
> 
> Let's keep in mind that veterans are much more likely to have to deal
> with very large programs than newbies, and so dealing with breakage
> for them is much harder than doing that in a toy program.  Thus, the
> proposal does "pressure the old very much".

Pressure for something they should have done decades ago if the code was
really maintained.
Anyway, I don't understand why these 3 (implicit fn declarations,
implicit ints and int-conversions) are so different from anything that
one needs to change in codebases every year as documented in
gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
more such changes than for C, but say GCC 12 no longer accepts
computed gotos with non-pointer types, GCC 10 changed default from
-fcommon to -fno-common for C which also affects dusty codebases
significantly, GCC 9 changed the lifetime of block scope compound literals
(again, affected various old codebases), GCC 5 broke bad user expectations
regarding preprocessor behavior by adding extra line markers to represent
whether certain tokens come from system headers or not, etc.
And of course compiler optimizations added every year can turn previously
"working" code with undefined behaviors in it into code not working as user
expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
what the problem is, tracking undefined behavior in code even when one
has sanitizers etc. is much more time consuming.

Can we stop this thread.  I'm afraid everything has been said multiple
times, it is up to the GCC Steering Committee to decide this if there is
disagreement on it among GCC developers, but my current understanding is
that that is not the case here and that the active GCC developers agree on
it.

	Jakub

Re: More C type errors by default for GCC 14

[Christian Groessler]

On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:
> 
>> With all that to consider, is it *really* a significant cost to add
>> -fpermissive?
> 
> See above (and my earlier message): the significant cost is to
> discover the root cause of the problem, and that -fpermissive is the
> solution.  The rest might be relatively easier, at least in some
> projects.


-fpermissive seems to be posted as the standard solution in this thread,

I don't know what constructs it allows, but it might enable things the 
user doesn't want besides silencing this new change.

So it seems to be more effort than to "just add -fpermissive" to get the 
code to compile again.

Think about big code bases where many developers are working on in 
different areas.

regards,
chris

Re: More C type errors by default for GCC 14

[Thomas Koenig]

On 12.05.23 09:53, Eli Zaretskii via Gcc wrote:
> I described in an earlier message how this breakage looks in real
> life, and why it causes a lot of frustration.  The main problem is
> discovering that things broke because GCC defaults, and then
> discovering how to pacify GCC with the least effort.

Gcc is quite helpful these days:

$ gcc -c example.c
example.c:1:1: warning: data definition has no type or storage class
     1 | a();
       | ^
example.c:1:1: warning: type defaults to 'int' in declaration of 'a' 
[-Wimplicit-int]
$ gcc -Werror -c example.c
example.c:1:1: error: data definition has no type or storage class [-Werror]
     1 | a();
       | ^
example.c:1:1: error: type defaults to 'int' in declaration of 'a' 
[-Werror=implicit-int]

(sorry, cannot show the nice coloring).

It tells you right in the error message which option caused the
or warning in question.  This is not hard.

Is your opinion that reading error messages (and making the mental
leap of adding the negative, of course) is too much to expect?

Best regards

	Thomas

Re: More C type errors by default for GCC 14

[Martin Jambor]

Hi,

On Tue, May 09 2023, Florian Weimer via Gcc wrote:
> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.
>

FWIW, I personally support the proposal.

Regarding the huge discussion that ensued, I would just like to point
out that the proposal is put forward by people from organizations which
are huge users of GCC and know perfectly well the transition will be
painful and yet are prepared face it, for reasons that were nicely
explained by Florian.  AFAIK, we at SUSE share the sentiment.

[...]

> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.

I like -fpermissive, but the -Wno-error-... options are actually quite
intuitive, perhaps we could do both?  But I do not have a strong
preference.

> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
>

So, a note to all users of cvise, creduce, delta etc.: Add appropriate
-Werror flags to your checking scripts so that we don't add more of this :-)

Thanks for putting effort into this.

Martin

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Fri, 12 May 2023 at 09:46, Christian Groessler <chris@groessler.org> wrote:
>
> On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:
> >
> >> With all that to consider, is it *really* a significant cost to add
> >> -fpermissive?
> >
> > See above (and my earlier message): the significant cost is to
> > discover the root cause of the problem, and that -fpermissive is the
> > solution.  The rest might be relatively easier, at least in some
> > projects.
>
>
> -fpermissive seems to be posted as the standard solution in this thread,
>
> I don't know what constructs it allows, but it might enable things the
> user doesn't want besides silencing this new change.

Currently that flag doesn't exist for C at all, so it will be added
with exactly the meaning of reverting the new change. Nothing more,
nothing less.

But if you don't want all of that (maybe you want to use implicit
function decls but not implicit int) then you will still have
individual flags to control those, so you don't have to use
-fpermissive.

You would be able to use -Wno-error=implicit-function-declaration to
just allow those, but keep giving errors for implicit int.

>
> So it seems to be more effort than to "just add -fpermissive" to get the
> code to compile again.

That's just speculation based on misunderstanding of the proposal. A
reasonable misunderstanding, but you'll be able to just disable the
errors that you don't want.


> Think about big code bases where many developers are working on in
> different areas.

Don't assume the people proposing this haven't thought about that, in
detail, for several years.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Fri, 12 May 2023 08:28:00 +0100
> Cc: Eli Schwartz <eschwartz93@gmail.com>, Po Lu <luangruo@yahoo.com>, 
> 	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> 
>  It is on topic because there doesn't seem to be anything in the
>  arguments brought up for this current proposal that couldn't be
>  brought up in favor of removing -fpermissive.  There are no guiding
>  principles being uttered which allow the current proposal, but will
>  disallow the removal of -fpermissive.  
> 
> "Let's change a default and add an option to get the old default" is really not the disaster you're making
> it out to be. You're becoming a laughing stock at this point.

I'm sad to hear that you consider this laughable.  I hope the
development team as a whole and the steering committee will consider
that more seriously.

>  The same "let's be more popular
>  and forthcoming to newbies, and more like Clang" PR-style stuff can
>  justify both.
> 
> It's not about popularity. If that's your takeaway then you're not paying attention, whatever you claim
> about reading everything in the thread. It's about helping people write correct code, first time, without
> some of the avoidable traps that C presents.

GCC already helps those people who want to be helped.  This was
pointed out several times.

> The C ecosystem has a shockingly bad reputation when it comes to security and "just don't write
> bugs" is naive and ineffective. Maybe you're good enough for that to work, but then you should also be
> able to cope with a change in defaults.
> 
> It's time for some defaults to change so that modern C is preferred, and "implicit everything, hope the
> programmer got it right" requires explicit action, *but it's still possible to do* for the 1970s nostalgia
> fans.

That's just a bunch of slogans.  Decisions about backward-incompatible
changes should do better than heed slogans.

>  > We might as well assume that the GCC developers are honest and truthful
>  > people, otherwise it is *definitely* a waste of time asking them about
>  > this change in the first place.
> 
>  This is not about honesty.  No one is questioning the honesty of GCC
>  developers.  What is being questioned are the overriding principles
>  that should be applied when backward-incompatible changes are
>  proposed.  Are there such principles in GCC development, and if there
>  are, where are they documented?  Or are such discussions just some
>  ad-hoc disputes, and the results are determined by which party is at
>  that time more vocal?
> 
> GCC has always taken backwards compatibility seriously. That doesn't mean it is the prime directive
> and can never be violated, but it's absolutely always considered.

Considered and dismissed, it seems, at least judging by your
responses.

As for when it can be violated, I already explained my opinions.
TL;DR: there are valid cases, but not in this case.

> In this case, changing the default
> seems appropriate to many people, including those who actually maintain gcc and deal with the
> consequences of the current defaults.

These decisions should not be based on majority votes.  Breaking even
one person's code is much worse than helping many others realize more
clearly their code needs to be fixed.

> Do you have anything new to add other than repeating the same arguments? We've heard them now,
> thanks.

Oh, please drop the attitude.  You are not making your arguments more
convincing by being hostile and ad-hominem.  We are supposed to have
the same goals.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Fri, 12 May 2023 10:15:45 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Arsen Arsenović <arsen@aarsen.me>, luangruo@yahoo.com,
>         jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> 
> On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > 
> > Let's keep in mind that veterans are much more likely to have to deal
> > with very large programs than newbies, and so dealing with breakage
> > for them is much harder than doing that in a toy program.  Thus, the
> > proposal does "pressure the old very much".
> 
> Pressure for something they should have done decades ago if the code was
> really maintained.

Why not assume that at least some of them didn't because they had good
reasons?

> Anyway, I don't understand why these 3 (implicit fn declarations,
> implicit ints and int-conversions) are so different from anything that
> one needs to change in codebases every year as documented in
> gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
> more such changes than for C, but say GCC 12 no longer accepts
> computed gotos with non-pointer types, GCC 10 changed default from
> -fcommon to -fno-common for C which also affects dusty codebases
> significantly, GCC 9 changed the lifetime of block scope compound literals
> (again, affected various old codebases), GCC 5 broke bad user expectations
> regarding preprocessor behavior by adding extra line markers to represent
> whether certain tokens come from system headers or not, etc.
> And of course compiler optimizations added every year can turn previously
> "working" code with undefined behaviors in it into code not working as user
> expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
> what the problem is, tracking undefined behavior in code even when one
> has sanitizers etc. is much more time consuming.

The difference, IMO, is that in all the cases you describe the changes
were done because they were necessary for GCC to support some new
feature, or fix a bug.  By contrast, in this case there's no new
features that require to fail to compile the code in question.

> Can we stop this thread.  I'm afraid everything has been said multiple
> times, it is up to the GCC Steering Committee to decide this if there is
> disagreement on it among GCC developers, but my current understanding is
> that that is not the case here and that the active GCC developers agree on
> it.

Fine, I will stop posting at this point.  Thanks for listening.

Re: More C type errors by default for GCC 14

[Pedro Alves]

On 2023-05-12 7:01 a.m., Po Lu via Gcc wrote:
> Jason Merrill <jason@redhat.com> writes:
> 
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
> 
> If it were so simple...
> 
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.

Then write a wrapper script named "cc", and put that in the PATH:

 $ cat cc
 #!/bin/sh

 exec /my/real/gcc -fwhatever "$@"

Done.

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/12/23 07:57, Po Lu via Gcc wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
>
>> There are ***not*** thousands of Makefiles that have this issue. But if
>> there were, then Makefiles are very easy to update, and only have to be
>> updated once per project, not thousands of times. So this is fine. You
>> may have to update your Makefile, but that is no big deal.
>>
>> It's still no big deal, no matter how much you dramatize the intensity
>> of adding a flag to your Makefiles.
> It's extra work.  Why don't I just write:
>
>    extern int foo ();
>
> above each of the new errors?
> That is just about what anyone will do when confronted by these new
> errors.  As a result, you have not ensured that any declarations are
> correct, but instead you have annoyed a lot of people and lulled
> yourself into a false sense of safety.

It's "extra work" to add 10 characters to a Makefile, but normal to add 
random faulty declarations everywhere ? I could only imagine someone 
doing this if they're being either extremely uninformed, extremely 
restricted (e.g. no change to any configuration files, no pragmas to 
disable the errors and not even having 10 seconds to look up the correct 
function prototype) or deliberately obtuse.

>
>> So you concede that GCC is not telling you, only trying and failing to
>> tell you?
> I concede that you're playing with words.
>
>> Great, so what's the problem? If GCC can't actually enforce it, and even
>> goes out of its way to offer you options to ignore what it's telling you
>> to do, then maybe...
>>
>> ... it's not telling you what to do with your code, only suggesting what
>> to do?
>>
>> So ignore the suggestion.
> Which is made annoying, especially when there is absolutely NO guarantee
> being made that the new option will stay.
>
>> I'm not sure what this semantics game here is trying to say. Is it
>> ethically and morally wrong for GCC to try to tell you what to do with
>> your code? Is it undignifying to have a mere machine go and lecture you,
>> a real human being with a consciousness and free will, what to do?
>>
>> Because if that's what this is about then I think you are taking this
>> inanimate object way too personally.
>>
>> If not, then I am simply entirely unsure what your objection is to being
>> "told".
>>
>>
>>>> Because that's exactly what is going on here. Features that were valid
>>>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>>>> ***not*** being valid GNU99 or GNU11 code.
>>> How GCC currently behaves defines what is valid GNU C.
>>
>> No. Absolutely positively 100% no under any circumstances whatsoever no.
>>
>> This has been explained multiple times by the GCC developers. e.g.
>> search for references to accepts-invalid.
>>
>> """
>> They are bugs where compiler accepts something that isn't valid in
>> the selected language nor considered valid extension.
>> So, after the fix we reject something that has been accepted before.
>>
>> In the last few years (checked what was fixed in 10/11/12/13 releases so
>> far), we've fixed 12 such bugs explicitly marked that way:
>> """
> The Standard states that each conforming implementation must be
> accompanied by a document which documents each and every extension.
>
> This document is the GCC manual, which makes reference (not too clearly,
> however, which should be fixed) to both implicit int and implicit
> function declarations, which are allowed in C99 and later dialects of C.
>
> These constructs are not bugs.  These constructs explicitly defined by
> GNU C; since a diagnostic is issued, GNU C's implementation also
> conforms to the Standard.
>
>> You cannot, and are not permitted, to define "how GCC currently behaves"
>> as "defines what is valid GNU C". No one agrees with your analysis. Most
>                                      ^^^^^^
>
> I'm not a person?
Now you're the one playing with words. That, or you have a complete lack 
of understanding of extremely common English expressions, which you may 
want to work on as you will otherwise inevitably have large problems 
effectively communicating anything with people on this list.
>
>> importantly, GCC does not agree with your analysis.
> For some definition of GCC, which is apparently you.
The "definition of GCC" used here is in a more general sense, i.e. the 
GCC project and the people involved in it that would be considered 
generally representative of it. In fact, so far on this thread I've seen 
almost nobody on your side of the argument, save for a very few 
extremely loud people repeating the same arguments over and over. So far 
I've seen only a single minor GCC contributor arguing the behavior 
should be kept as-is - pretty much everyone else agrees the behavior 
should be changed. In fact, I've talked to many people who are not 
currently posting in this thread, who consider that the default should 
be changed, and are watching in consternation as a few people appear to 
be trying to hold back the entire community with extremely bad defaults.
>
>> It's a wild, wild, wild claim to begin with. You are arguing that any
>> bug, ANY bug whatsoever, which qualifies for the title "how GCC
>> currently behaves" because if a bug is currently present, then GCC
>> currently behaves in a buggy manner...
>>
>> ... any such bug is, ***because*** GCC currently does it, now part of
>> the documentation on "GNU C", a language dialect with documentation.
>>
>> Can you show me where on
>> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
>> documentation states that "C Extensions include anything that GCC
>> currently does, no matter what, no matter how documented or undocumented"?
> I see:
>
> `-Wno-implicit-int (C and Objective-C only)'
>       This option controls warnings when a declaration does not specify a
>       type.  This warning is enabled by default in C99 and later dialects
>       of C, and also by `-Wall'.
>
> `-Wno-implicit-function-declaration (C and Objective-C only)'
>       This option controls warnings when a function is used before being
>       declared.  This warning is enabled by default in C99 and later
>       dialects of C, and also by `-Wall'.  The warning is made into an
>       error by `-pedantic-errors'.
In the "C Extensions" section ?
>> The concept of a language extension has bulletproof meaning. You cannot
>> get around it, redefine it, pretend that something is when it isn't, or
>> otherwise disagree with this bulletproof meaning.
> The concept of a ``language extension'' is not defined anywhere.
> Instead, there are three kinds of behavior not precisely specified by
> the Standard:
>
>    - undefined behavior, the behavior upon use of an erroneous construct
>      for which the Standard imposes no requirements whatsoever.
>
>    - unspecified behavior, where upon the use of a construct for which
>      the Standard imposes two or more possible behaviors, and leaves the
>      selected behavior unspecified.
>
>    - implementation-defined behavior, unspecified behavior where each
>      implementation documents how the choice is made, and is required to
>      document that choice.
>
> If the translator precisely defines either undefined behavior (in this
> case, erroneous syntax) or unspecified behavior, then that definition is
> commonly considered to be an extension of that translator.  Nothing
> gcc.info says will change that.
>
>> The compiler defines an extension by writing about it in its
>> documentation on "GNU C extensions".
>>
>> Anything else you have to say on the topic is automatically wrong.
>>
>> Language has meaning. *Words* have meaning. The word "extension" has a
>> very specific meaning in the GCC documentation. You can read all about
>> it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
> GNU C documentation does not decide what is an extension and what is
> not.  In any case, if (gcc)C Extensions does not mention extensions
> currently implemented by GCC, then that is a bug in the documentation,
> is it not?  Documentation is supposed to reflect what the program being
> documented does, not the other way around.  Like the Standard says:
>
>    An implementation shall be accompanied by a document that defines all
>    implementation- defined and locale-specific characteristics and all
>    extensions.

By the same line of argumentation, any accepts-invalid is actually not a 
bug and should instead be considered a documentation bug that should be 
fixed by altering the documentation rather than fixing the actual bug 
(given that you appear to consider that making GCC not accept code that 
it previously accepted by default is something that should never be 
done). I hope you understand that's not a reasonable line of argumentation.

>> I did not dictate that you have to rewrite your code. You are replying
>> to something that has no relationship whatsoever to any form of
>> instruction, telling, or even ***advice***, and calling it dictation. I
>> reiterate: this paragraph was me ***observing*** a fact. That fact is
>> that if someone happens to do X, then they will not be affected by this
>> discussion.
>>
>> (X is, in this case, "someone wrote ANSI C code and also chose to use a
>> flag telling the compiler that it is ANSI C".)
>>
>>
>> But, furthermore, I would like to now clarify something anyway.
>>
>> You are not writing GNU C code, you never have been. GNU C code is
>> defined by the documentation for GNU C:
>> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
>>
>> You may take this as me dictating to you that you are not to call this
>> code "GNU C".
> Really?  Then why is __GNUC__ defined, and why does it compile with
> `gcc'?
To be honest, I'd be inclined to consider the current behavior a 
longstanding bug that's been wrongly considered to be a WONTFIX for many 
years, and that we're only now getting around to fixing, if you really 
want to go down this line of argumentation.
>
>> My opinion on this is (still) that if your argument is that you don't
>> want -fpermissive or -std=c89 to be removed, you are more than welcome
>> to be skeptical about that (either one or both), but I don't see why
>> that is on topic for the question of whether things should be moved to
>> flags such as those while they do exist.
>>
>> If they want to remove -fpermissive, or -std=c89, out of an
>> unwillingness to provide compilers capable of being instructed to accept
>> and compile your coding style, then they will do so regardless of this
>> conversation.
>>
>> We might as well assume that the GCC developers are honest and truthful
>> people, otherwise it is *definitely* a waste of time asking them about
>> this change in the first place.
> How honest and truthful they are does not reflect whether or not the
> proposed new option will be kept around.  In fact, I observe that none
> of them have committed to supporting such an option indefinitely.

Actually, now that I think about it, what are you actually trying to get 
from this conversation ? If you're unsatisfied with a lack of commitment 
from the maintainers to maintain a `-fpermissive` option indefinitely, 
it seems like you can't possibly be satisfied with the current 
situation, either. It seems like what you actually want is an eternal 
commitment from the GCC developers to never ever change the behavior of 
GCC ever in any way that could ever break any of your old broken code...

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:
>> Date: Thu, 11 May 2023 18:43:32 -0400
>> Cc: luangruo@yahoo.com, gcc@gcc.gnu.org
>> From: Eli Schwartz <eschwartz93@gmail.com>
>>
>> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
>>
>>> Back to the subject: the guarantees I would personally like to have is
>>> that the current GCC development team sees backward compatibility as
>>> an important goal, and will try not to break old programs without very
>>> good technical reasons.  At least in Emacs development, that is the
>>> consideration that is very high on our priority list when making
>>> development decisions.  It would be nice if GCC (and any other GNU
>>> project, for that matter) would do the same, because being able to
>>> upgrade important tools and packages without fear is something users
>>> value very much.  Take it from someone who uses GCC on various
>>> platforms since version 1.40.
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
> They are not technical, no.  Leaving the current behavior does not
> technically hamper GCC and its users in any way -- GCC can still
> compile the same programs, including those with modern std= values, as
> it did before, and no false warnings or errors are caused when
> compiling programs written in valid standard C.

The current behavior hampers GCC's users in very significant ways: it 
encourages people who are new to the language to write completely broken 
code in ways that should have been at least slightly harder to 
accomplish since a quarter of a century ago.

Arguing that GCC should compile any "valid standard C" seems like an 
obviously flawed premise to me given that unless you're going the 
strictly conforming route, a "program" such as:

]iN$<\J3"`q
Tf;9ge0k\hm[
!Zsr>MtiV B@
~x?M\A):.s0^W
2$((g]'Vx:jZ
D'?n/X_li|;E
aLA%WQmzNq-(QG'
r"rSV3|]k_BU?R
p:hPWg_(]Y(
And,3xD{iR5B

may be considered by any implementation as a valid standard C program, 
since it does not contain an #error directive.

Such examples may seem like hyperbole to you, but to a beginner, the 
constructs that you wish to leave usable in GCC unaltered may well be 
just about as confusing as you might find any interpretation of the 
valid standard C program presented above to be.

You may not be aware of this, but the current behavior leads to endless 
instances of beginners accidentally using utterly broken constructs and 
then coming to C forums/channels/etc. asking for help, only for people 
like me to discover that such code is still compiled by GCC now without 
anymore than a warning being given to the user (which they extremely 
commonly ignore). Having been on such forums for years, I'd estimate 
that this actually represents a genuinely significant proportion of the 
problems I help diagnose - about 10% or so (though I have of course not 
made a detailed study of every problem I've ever helped solve, but I'm 
relatively confident 10% is not too far from the real proportion). To be 
honest, it's such a common problem that I'm genuinely surprised it 
hasn't spawned off jokes in the same way things like 
T_PAAMAYIM_NEKUDOTAYIM in PHP have (I guess "implicit function 
declaration" has less of a ring to it than T_PAAMAYIM_NEKUDOTAYIM)

>
> The reasons are basically PR: better reputation for GCC etc.  Maybe
> even fashion: Clang does that, so how come we don't?
>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
> I already did, in previous messages, where I described what we all are
> familiar with: the plight of a maintainer of a large software system
> whose build suddenly breaks, and the difficulty in understanding which
> part of the system's upgrade caused that.  I'd rather not repeat that:
> there are already too many repetitions here that make the discussion
> harder to follow.

Re: More C type errors by default for GCC 14

[David Brown]

On 12/05/2023 04:08, Po Lu via Gcc wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
> 

>>
>> Because that's exactly what is going on here. Features that were valid
>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>> ***not*** being valid GNU99 or GNU11 code.
> 
> How GCC currently behaves defines what is valid GNU C.
> 

What GCC /documents/ defines what is valid GNU C.  (Much of that is, of 
course, imported by reference from the ISO C standards, along with 
target-specific details such as ABI's.)

Anything you write that relies on undocumented behaviour may work by 
luck, not design, and you have no basis for expecting future versions of 
gcc, or any other compiler, to give the same lucky results.

Each version of a compiler is, in fact, a different compiler - that is 
how you should be viewing your tools.  The move between different 
versions of the same compiler is usually much smaller than moving 
between different compiler vendors, but you still look at the release 
notes, change notices, porting information, etc., before changing.  You 
still make considered decisions, and appropriate testing.  You still 
check your build systems and modify flags if needed.  And you do that 
even if you are confident that your code is solid with fully defined 
behaviour and conforming to modern C standards - you might have a bug 
somewhere, and the new compiler version might have a bug.


>> I am not dictating anything to you or anyone else in this paragraph,
>> though? All I said was that if one writes a c89 program and tells the
>> compiler that, then they will not even notice this entire discussion to
>> begin with.
>>
>> What, precisely, have I dictated?
> 
> That people who are writing GNU C code should be forced to rewrite their
> code in ANSI C, in order to make use of GNU C extensions to the 1999
> Standard.
> 

You are joking, right?  Surely no one can /still/ be under the 
misapprehension that anyone is proposing GCC stop accepting the old 
code?  All that is changing is the default behaviour, which will mean 
some people might have to use an extra flag or two in their build setup.

> 
>> However, it does appear that we are still stuck in confusion here,
>> because you think that GCC is no longer able to compile such code, when
>> in fact it is able to.
> 
> It won't, not by default.
> 

That's pretty much irrelevant.  People don't use gcc without flags.  The 
only thing that will change is which flags you need to use.

If you are not in a position to change the source code, and not in a 
position to change the build flags, then you are not in a position to 
change the compiler version.  (That's fine, of course - in my line of 
work, I almost never change compiler version for existing projects.  I 
have old code where the makefile specifies gcc 2.95.)

David

Is the GNUC dialect anything that GCC does when given source code containing UB? (Was: More C type errors by default for GCC 14)

[Eli Schwartz]

On 5/12/23 1:57 AM, Po Lu wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
>> It's still no big deal, no matter how much you dramatize the intensity
>> of adding a flag to your Makefiles.
> 
> It's extra work.  Why don't I just write:
> 
>   extern int foo ();
> 
> above each of the new errors?
> That is just about what anyone will do when confronted by these new
> errors.  As a result, you have not ensured that any declarations are
> correct, but instead you have annoyed a lot of people and lulled
> yourself into a false sense of safety.


Instead of adding one flag to their Makefile, which is too much work,
they will add *many* declarations of `extern int foo();` across many
source files in the same project?

Very interesting definition of burdensome work.

You keep saying "just about what anyone will do", but I do not believe
this is what anyone other than you will do.


> This document is the GCC manual, which makes reference (not too clearly,
> however, which should be fixed) to both implicit int and implicit
> function declarations, which are allowed in C99 and later dialects of C.
> 
> These constructs are not bugs.  These constructs explicitly defined by
> GNU C; since a diagnostic is issued, GNU C's implementation also
> conforms to the Standard.


You reading is faulty, and your beliefs about how software work are also
faulty, if you believe that the issuance of a diagnostic is what
constitutes adding new features to the language dialect called "GNU C".

Please start a new thread, titled something like "the documentation is
flawed, which should be fixed, because implicit function declarations
are referenced but not to clearly". Argue there, that implicit function
declarations should be documented on the "C Extensions" page.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.


>> You cannot, and are not permitted, to define "how GCC currently behaves"
>> as "defines what is valid GNU C". No one agrees with your analysis. Most
>                                     ^^^^^^
> 
> I'm not a person?


"no one agrees with you" is a common idiom that states that a person (in
this case Po Lu) holds an opinion that rest of the world (all persons
not named Po Lu) do not hold.

Since you cannot agree with yourself -- you are yourself -- I am forced
to believe that you are trolling by accusing me of denying you personhood.


>> importantly, GCC does not agree with your analysis.
> 
> For some definition of GCC, which is apparently you.


No, just the GCC manual.


>> It's a wild, wild, wild claim to begin with. You are arguing that any
>> bug, ANY bug whatsoever, which qualifies for the title "how GCC
>> currently behaves" because if a bug is currently present, then GCC
>> currently behaves in a buggy manner...
>>
>> ... any such bug is, ***because*** GCC currently does it, now part of
>> the documentation on "GNU C", a language dialect with documentation.
>>
>> Can you show me where on
>> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
>> documentation states that "C Extensions include anything that GCC
>> currently does, no matter what, no matter how documented or undocumented"?
> 
> I see:
> 
> `-Wno-implicit-int (C and Objective-C only)'
>      This option controls warnings when a declaration does not specify a
>      type.  This warning is enabled by default in C99 and later dialects
>      of C, and also by `-Wall'.
> 
> `-Wno-implicit-function-declaration (C and Objective-C only)'
>      This option controls warnings when a function is used before being
>      declared.  This warning is enabled by default in C99 and later
>      dialects of C, and also by `-Wall'.  The warning is made into an
>      error by `-pedantic-errors'.


Irrelevant, I shall ignore this comment -- it is not listed on the "C
Extensions" page.


>> The concept of a language extension has bulletproof meaning. You cannot
>> get around it, redefine it, pretend that something is when it isn't, or
>> otherwise disagree with this bulletproof meaning.
> 
> The concept of a ``language extension'' is not defined anywhere.
> Instead, there are three kinds of behavior not precisely specified by
> the Standard:


The concept of a language extension is defined by the page that says
"these are the extensions to the language". Please take your mendacious
reading of the C standard and put it back where you got it from.


>   - undefined behavior, the behavior upon use of an erroneous construct
>     for which the Standard imposes no requirements whatsoever.
> 
>   - unspecified behavior, where upon the use of a construct for which
>     the Standard imposes two or more possible behaviors, and leaves the
>     selected behavior unspecified.
> 
>   - implementation-defined behavior, unspecified behavior where each
>     implementation documents how the choice is made, and is required to
>     document that choice.
> 
> If the translator precisely defines either undefined behavior (in this
> case, erroneous syntax) or unspecified behavior, then that definition is
> commonly considered to be an extension of that translator.  Nothing
> gcc.info says will change that.


... because the GNUC language dialect is not synonymous with either
undefined, unspecified, or implementation defined behavior. Quoting
random definitions of things that aren't "C Extensions" don't make them
C Extensions.

I also find it difficult to understand how adding a diagnostic telling
you not to do something would be synonymous with "precisely defines"
doing that thing. There's nothing precise about it?

"Nothing gcc.info says will change that". What? Please tell me how this
can be so. What precisely defines the behavior if not the manual?
Defining something is to create a description of that thing. English
language prose is the standard for creating descriptions. That's the
documentation. What else are you looking at here?

> GNU C documentation does not decide what is an extension and what is
> not.


I am framing this and putting it on my wall.


> In any case, if (gcc)C Extensions does not mention extensions
> currently implemented by GCC, then that is a bug in the documentation,
> is it not?  Documentation is supposed to reflect what the program being
> documented does, not the other way around.  Like the Standard says:
> 
>   An implementation shall be accompanied by a document that defines all
>   implementation- defined and locale-specific characteristics and all
>   extensions.


Please submit a bug report to GCC requesting that this be added to a
section titled "implementation-defined and locale-specific characteristics".

Do not expect it to be added to a section titled "C Extensions to the
language, which shall be known as the acceptable GNUC dialect".


>> You are not writing GNU C code, you never have been. GNU C code is
>> defined by the documentation for GNU C:
>> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
>>
>> You may take this as me dictating to you that you are not to call this
>> code "GNU C".
> 
> Really?  Then why is __GNUC__ defined, and why does it compile with
> `gcc'?


Why does C++ compile with `gcc` as long as it has the right heuristic
file extension?

Why is __GNUC__ defined when you specifically ask for -std=c89, which is
not -std=gnu89?

I assume because the compiler is kind and forgiving, and will often
allow you to mix dialects even though you shouldn't, if it can be done
safely and without conflicting other stds.


But implicit-function-declarations cannot be done safely.

...


This discussion is going nowhere until you accept that GNUC has a
definition and that definition is separate from "what GCC does when
given UB".


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/12/23 2:01 AM, Po Lu wrote:
> Jason Merrill <jason@redhat.com> writes:
> 
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
> 
> If it were so simple...
> 
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.
> 
> These programs are intended to be as portable as possible (naturally,
> since Autoconf does not configure for the build machine).  As a result,
> they are typically written in the subset of ANSI C that will compile
> with almost any C compiler, which is exactly what will cause problems
> with GCC's proposed new defaults.


This sounds like a "you" problem.

If your Makefiles are totally incapable of respecting the user's choice
of C compiler, you may need to do the same thing that you'd do to
compile it with any alternative compiler: add a directory to your path
containing a wrapper script called "cc" which runs /opt/tinyc/bin/tcc
"$@" or aarch64-linux-gnu-gcc "$@" or whatever.

Although in this case it could just call /usr/bin/gcc -fpermissive "$@"


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > One fairly big GCC-internal task is to clear up the C test suite so that
> > it passes with the new compiler defaults.  I already have an offer of
> > help for that, so I think we can complete this work in a reasonable time
> > frame.

I'd prefer to keep at least significant portion of those tests as is with
-fpermissive added (plus of course we need new tests that verify the errors
are emitted), so that we have some testsuite coverage for those.

> So, a note to all users of cvise, creduce, delta etc.: Add appropriate
> -Werror flags to your checking scripts so that we don't add more of this :-)

While it is true that for C cvise/creduce/delta often end up with the
implicit ints/implicit function declarations/int-conversions because it
happens to still compile without errors, I and others routinely fix up those
testcases back to valid C provided they still reproduce the reported
problem, so I think it isn't that bad in our testsuite.
But for cvise/creduce/delta reduced testcases with GCC 14 the nice things is
that most of the time these constructs will be gone ;)

Note, using -Werror for all warnings for testsuite reduction often results
in much slower reduction process and larger end result compared to allowing
some warnings but then fixing them up by hand where possible if it still
reproduces.

	Jakub

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/12/23 04:36, Po Lu via Gcc wrote:
> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Indeed they should be - but warning vs. error holds significance.  A
>> beginner is much less likely to be writing clever code that allegedly
>> uses these features properly than to be building new code, and simply
>> having made an error that they do not want and will suffer through
>> confused.
> Most programs already paste a chunk of Autoconf into their configure.ins
> which turns on more diagnostics if it looks like the program is being
> built by a developer.  i.e. from Emacs:
>
> AC_ARG_ENABLE([gcc-warnings],
>    [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
>                    [control generation of GCC warnings.  The TYPE 'yes'
> 		   means to fail if any warnings are issued; 'warn-only'
> 		   means issue warnings without failing (default for
> 		   developer builds); 'no' means disable warnings
> 		   (default for non-developer builds).])],
>    [case $enableval in
>       yes|no|warn-only) ;;
>       *)      AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
>     esac
>     gl_gcc_warnings=$enableval],
>    [# By default, use 'warn-only' if it looks like the invoker of 'configure'
>     # is a developer as opposed to a builder.  This is most likely true
>     # if GCC is recent enough and there is a .git directory or file;
>     # however, if there is also a .tarball-version file it is probably
>     # just a release imported into Git for patch management.
>     gl_gcc_warnings=no
>     if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
>        # Clang typically identifies itself as GCC 4.2 or something similar
>        # even if it is recent enough to accept the warnings we enable.
>        AS_IF([test "$emacs_cv_clang" = yes],
>           [gl_gcc_warnings=warn-only],
>           [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
>     fi])
>
> So this is really not a problem.
>
>> Indeed.  I said facilitates, not treats equally.  I think the veterans
>> here won't lose much by having to pass -fpermissive, and I think that's
>> a worthwhile sacrifice to make, to nurture the new without pressuring
>> the old very much.
> Until `-fpermissive' goes the way of `-traditional',
> `-fwritable-strings'.
>
>> On that note - lets presume a beginners role.  I've just started using
>> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
>> mentions some 'implicit function generation', dunno what that means - if
>> it mattered much, it'd have been an error.  I wrote a function called
>> test that prints the int it got in hex, but I called it with 12.3, but
>> it printed 1.. what the heck?
> Have you actually seen anyone make this mistake?
As somebody that spends a lot of time helping beginners, yes, 
constantly. I'd go as far as to say it's an error that seemingly 
everyone has made at least once.
>
>> Why that happened is obvious to you and I (if you're on the same CPU as
>> me), but to a beginner is utter nonsense.
>>
>> At this point, I can only assume one goes to revisit that warning..  I'd
>> hope so at least.
>>
>> I doubt the beginner would know to pass
>> -Werror=implicit-function-declaration in this case (or even about
>> Werror...  I just told them what -Wall and to read the warnings, which
>> was gleefully ignored)
> I'd expect a question from the newbie, directed at a web search engine.
>
>> Hell, I've seen professors do it, and for a simple reason: they knew how
>> to write code, not how to use a compiler.  That's a big gap.
>>
>> The beginner here can't adapt - they don't know what -Wall means, they
>> just pass it because they were told to do it (if they're lucky!).
> If this is really such a bad problem, then how about clarifying the
> error message?
>
>> At the same time, they lose out on what is, IMO, one of the most useful
>> pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
>> it by default.. we do).  It provides effective bug detection, when the
>> code compiles right.  It regularly spots bugs that haven't happened yet
>> for me.
>>
>> (and same goes for all the other useful analysis the toolchain can do
>> when it has sufficient information to generate correct code, or more;
>> some of which can't reasonably be a default)
>>
>> (on a related note, IMO it's a shame that the toolchain hides so many
>> possibilities behind 'cult knowledge', depths of many manuals and bad
>> defaults)
> _FORTIFY_SOURCE is not really important enough to be considered here.
> It's not even available everywhere.
>
>> This sample is subject to selection bias.  My testing targets mostly
>> more modern codebases that have long fixed these errors (if they have
>> active maintainers), and exclusively Free Software, so I expect that the
>> likelyhood that you'll need to run `export CC='gcc -fpermissive'
>> CXX='g++ -fpermissive'` goes up the more you move towards old or more
>> corporate codebases, but, for a veteran, this is no cost at all.
>>
>> Is it that much of a stretch to imagine that a maintainer of a codebase
>> that has not seen revisions to get it past K&R-esque practices would
>> know that they need to pass -std=c89 (or a variant of such), or even
>> -fpermissive - assuming that they could even spare to use GCC 14 as
>> opposed to 2.95?
> There's bash, which still tries to work on later 4.3BSDs (AFAIK), while
> also building with just `gcc'.
>
>> As an anecdote, just recently I had to fix some code written for i686
>> CPUs, presumably for GCC 4.something or less, because the GCC I insist
>> on using (which is 13 and has been since 13.0 went into feature-freeze)
>> has started using more than the GPRs on that machine (which lead to hard
>> to debug crashes because said codebase does not enable the requisite CPU
>> extensions, or handle the requisite registers properly).  I think this
>> fits within the definition of 'worked yesterday, broke today'.  Should
>> that change be reverted?  Replacing it with -mmore-than-gprs would make
>> GCC more compatible with this old code.
>>
>> I don't think so.
>>
>> This is a sensitive codebase, and not just because it's written poorly,
>> but because it's a touchy thing it's implementing, any change in
>> compiler requires reverification.  The manifestation here has *no*
>> significance.
> And the problematic part of the code in question is implementing
> something like swapcontext in assembler, correct?  That's a far cry from
> breaking C code, which does have clearly defined (albeit not exactly
> intuitive) semantics.
>
>> ... speaking of that, if one builds their codebase without -std=..,
>> they're risking more than just optimization changes breaking code that
>> relies on bad assumptions, they're also risking a change in language
>> semantics..
> The Standards committee does have a reasonable track record of keeping
> backwards compatibility, since they prioritize existing practice and the
> existing body of C code.  So I'm not too worried about that.
>
>> With all that to consider, is it *really* a significant cost to add
>> -fpermissive?
> Yes, in case it goes away.
>
>> Would that cost not be massively overshadowed by the cost
>> of a compiler change?  It feels like it's a footnote compared to
>> checking whether added optimizations go against invalid assumptions
>> (which is, by the way, also rectified by adding more hard and easy
>> to see errors).
>>
>> I expect no change in behavior from those that maintain these old
>> codebases, they know what they're doing, and they have bigger fish to
>> fry - however, I expect that this change will result in:
>>
>> - A better reputation for GCC and the GCC project (by showing that we do
>>    care for code correctness),
> A compiler should care about the correctness of its own code, not that
> of others.
>
>> - More new code being less error prone (by merit of simple errors being
>>    detected more often),
> As I said, making such things errors will simply result in people
> inserting `extern' declarations everywhere, which may or may not be
> wrong.  I've seen this happen before with my own eyes.
>
>> - Less 'cult knowledge' in the garden path,
> I guess search engines, and better written diagnostic messages, would be
> enough to accomplish that?
>
>> - More responsible beginners, and
>> - Fewer people being able to effectively paint GNU and/or C/++ as the
>>    backwards crowd using a error-prone technique of yesteryear.
> This never worked in GNU C++, right?
>
>> (and yes, optics matter)
>>
>> Builds break.  Builds breaking cleanly is a treat compared to the usual
>> breakage.  At least this breaks the few that do break with a positive
>> outcome.
> Builds shouldn't break, and the ``usual treat'' should also not
> happen...

Re: Is the GNUC dialect anything that GCC does when given source code containing UB?

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Instead of adding one flag to their Makefile, which is too much work,

Once again, you're making the silly assumption that adding
`-fpermissive' to many different Makefiles is easy.  Especially when the
Makefiles also have to be used with compilers which do not understand
such an option.

> they will add *many* declarations of `extern int foo();` across many
> source files in the same project?

Yes: it's less work.

> Very interesting definition of burdensome work.
>
> You keep saying "just about what anyone will do", but I do not believe
> this is what anyone other than you will do.

I've seen people do this.  If you place yourself in the position of
either a user installing a program he is unfamilar with, a user who does
not know that `-fpermissive' exists, or a programmer operating under
time constraints, then you will quickly find yourself doing the same
thing.

> You reading is faulty, and your beliefs about how software work are also
> faulty, if you believe that the issuance of a diagnostic is what
> constitutes adding new features to the language dialect called "GNU C".

Which part of ``also'' do you not understand?
From n1124:

  A conforming implementation shall produce at least one diagnostic
  message (identified in an implementation-defined manner) if a
  preprocessing translation unit or translation unit contains a
  violation of any syntax rule or constraint, even if the behavior is
  also explicitly specified as undefined or implementation-defined.

Implicit int is a violation of various kinds of declaration syntax, and
the Standard does not place any requirements on the behavior of the
translator/implementation after the diagnostic is issued, but GCC
explicitly defines how it translates such syntax.  Making it an
extension.

> Please start a new thread, titled something like "the documentation is
> flawed, which should be fixed, because implicit function declarations
> are referenced but not to clearly". Argue there, that implicit function
> declarations should be documented on the "C Extensions" page.
>
> Until everyone is on the same page as you about whether these are GNUC
> extensions, this conversation will go nowhere.

Please.  I ask you this: where in the manual is it described that the
behavior of the compiler defers to the manual, and not the other way
around?

> "no one agrees with you" is a common idiom that states that a person (in
> this case Po Lu) holds an opinion that rest of the world (all persons
> not named Po Lu) do not hold.
>
> Since you cannot agree with yourself -- you are yourself -- I am forced
> to believe that you are trolling by accusing me of denying you personhood.

No, I'm simply describing that you speak for yourself, and nobody else.
Just like I do.

> No, just the GCC manual.

See above.

> Irrelevant, I shall ignore this comment -- it is not listed on the "C
> Extensions" page.

And where does the manual say that (gcc)C Extensions node is the only
document describing extensions to the language implemented by the GNU C
translator?

> The concept of a language extension is defined by the page that says
> "these are the extensions to the language". Please take your mendacious
> reading of the C standard and put it back where you got it from.

How is my reading of the Standard incorrect?

>>   - undefined behavior, the behavior upon use of an erroneous construct
>>     for which the Standard imposes no requirements whatsoever.
>> 
>>   - unspecified behavior, where upon the use of a construct for which
>>     the Standard imposes two or more possible behaviors, and leaves the
>>     selected behavior unspecified.
>> 
>>   - implementation-defined behavior, unspecified behavior where each
>>     implementation documents how the choice is made, and is required to
>>     document that choice.
>> 
>> If the translator precisely defines either undefined behavior (in this
>> case, erroneous syntax) or unspecified behavior, then that definition is
>> commonly considered to be an extension of that translator.  Nothing
>> gcc.info says will change that.
>
>
> ... because the GNUC language dialect is not synonymous with either
> undefined, unspecified, or implementation defined behavior. Quoting
> random definitions of things that aren't "C Extensions" don't make them
> C Extensions.

Erroneous constructs leading to the issuance of a diagnostic message are
undefined behavior.

> I also find it difficult to understand how adding a diagnostic telling
> you not to do something would be synonymous with "precisely defines"
> doing that thing. There's nothing precise about it?

Because translation proceeds as if:

   register k, j;

was:

   register int k, j;

and:

   gettimeofday (&tv, 0L);

proceeds as if:

   extern int gettimeofday ();

was placed above `gettimeofday' at (I believe) file scope.  I don't see
how this could be any less precisely defined.

> "Nothing gcc.info says will change that". What? Please tell me how this
> can be so. What precisely defines the behavior if not the manual?

The C translator itself.

> Defining something is to create a description of that thing. English
> language prose is the standard for creating descriptions. That's the
> documentation. What else are you looking at here?

C++ is no less suitable for this purpose, especially when the English
language description seems to be missing.

> Why does C++ compile with `gcc` as long as it has the right heuristic
> file extension?
>
> Why is __GNUC__ defined when you specifically ask for -std=c89, which is
> not -std=gnu89?

Because it's specifically allowed by the Standard?

  All predefined macro names shall begin with a leading underscore
  followed by an upper-case letter or a second underscore.

> I assume because the compiler is kind and forgiving, and will often
> allow you to mix dialects even though you shouldn't, if it can be done
> safely and without conflicting other stds.

???

> But implicit-function-declarations cannot be done safely.

Really?  Why?

Now you're really speaking for yourself, and yourself alone.  So please
explain how you arrived at this conclusion.

> This discussion is going nowhere until you accept that GNUC has a
> definition and that definition is separate from "what GCC does when
> given UB".

Oh, I do recognize that difference.  Conversely, you seem not to have
recognized the difference between behavior that is explicitly defined by
GNU C, in c-decl.c, and behavior that GNU C does not define at all, such
as the result of dereferencing a pointer to NULL.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> It's not about popularity. If that's your takeaway then you're not
> paying attention, whatever you claim about reading everything in the
> thread.  It's about helping people write correct code, first time,
> without some of the avoidable traps that C presents.
>
> The C ecosystem has a shockingly bad reputation when it comes to
> security and "just don't write bugs" is naive and ineffective. Maybe
> you're good enough for that to work, but then you should also be able
> to cope with a change in defaults.

Right, and how many percent of those came from implicit function
declarations?  Implicit int?  Extern declarations in function scope
being applied at file scope?  Arithmetic between floats being done as
doubles?  Narrow-type promotion to unsigned int?

> It's time for some defaults to change so that modern C is preferred,
> and "implicit everything, hope the programmer got it right" requires
> explicit action, *but it's still possible to do* for the 1970s
> nostalgia fans.

It is impossible for implicit int to lead to bugs.

> If you want to believe that's the start of a slippery slope, that's
> your choice. The nostalgia club can always fork gcc if necessary,
> that's one of the great things about free software.

I am not part of a nostalgia club, so you might as well stop using this
label.  In courtrooms, the plantiffs may be precluded from using
terminology that can mislead the jury.  This is more or less equivalent.

> GCC has always taken backwards compatibility seriously. That doesn't
> mean it is the prime directive and can never be violated, but it's
> absolutely always considered. In this case, changing the default seems
> appropriate to many people, including those who actually maintain gcc
> and deal with the consequences of the current defaults.

What consequences?  Really?

> Do you have anything new to add other than repeating the same
> arguments? We've heard them now, thanks.

Yes, just these quotes from a former GCC maintainer:

  In C, we cannot divide all user code into "right" and "wrong" in this
  kind of simple way, and certainly not based on the ISO standard.  That
  standard is just the decisions of a certain committee (which I was a
  member of) about what cases conforming compilers should commit to
  support.  We must not let ourselves start thinking that C code is
  "wrong", just because it is not conforming ISO C code.

  C programs use many cases that are not conforming, but do work.  This
  will be true for as long as C is used, because changing it would
  require major changes in the C language.

  From time to time, there is a real *need* to make some of these cases
  stop working, for the sake of some benefit that users want.  When this
  happens, we should do it; the user community will accept it, because
  they will see that it is being done for their sake.  Some will
  grumble, but the users who appreciate the benefits will convince them.

  But when there is no *need* to break these cases, when we can keep
  them working fairly easily, we should keep them working.  If we break
  them unnecessarily, we invite the legitimate anger of the users.

and:

  You are arguing for a position that rejects the very idea of making an
  effort to keep old code working.  Your arguments support a general
  conclusion that "If code is not unambiguously valid, it is better to
  break the code than to keep it working."

  This is not just a harsh policy, it is an explicit policy of being
  harsh.  That is, it says, "Be harsh!  Choose the alternative that is
  harsh!"  This is the opposite of the way we should treat our users.

  I understand that your views are not based on sadism or cruelty; you
  think that treating users harshly is better for them.  But your
  motivation, like my motivation, is not the issue anyway.  To adopt a
  policy of harshness towards people--no matter what justification is
  offered for it--is treating them badly.  That is the wrong way to
  treat the users.  We must not make GCC decisions based on a policy of
  harshness.

  I would like future GCC decisions to be based on the policy that
  keeping old code working is a good thing to do, when it is practical
  of course.

  So if any argument leads to the conclusion that one should be harsh to
  the users, please recognize where the argument is taking you, and
  reject it on the grounds that it is a disguised policy of harshness.

  In particular, if it is argued that a policy of kindness has a
  disadvantage, and it turns out that the disadvantage is a consequence
  of the fact that the users have been treated kindly, it is really a
  disguised policy of harshness.

It is sad that this mature attitude no longer seems to be prevalent
among the current maintainership.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> Then they should not use implicit int and implicit function
> declarations.

And why is that?  Is GCC really arrogant enough to think that it is the
only C translator in the world?

BTW, standards.info used to say something along the lines of:

  Do not declare functions whose definitions differ between
  systems.  Especially, do not declare any prototypes for them.
  The implicit declaration is likely to be correct.

However, I cannot find it anymore.

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/12/23 15:19, Po Lu via Gcc wrote:
> Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>
>> It's not about popularity. If that's your takeaway then you're not
>> paying attention, whatever you claim about reading everything in the
>> thread.  It's about helping people write correct code, first time,
>> without some of the avoidable traps that C presents.
>>
>> The C ecosystem has a shockingly bad reputation when it comes to
>> security and "just don't write bugs" is naive and ineffective. Maybe
>> you're good enough for that to work, but then you should also be able
>> to cope with a change in defaults.
> Right, and how many percent of those came from implicit function
> declarations?  Implicit int?  Extern declarations in function scope
> being applied at file scope?  Arithmetic between floats being done as
> doubles?  Narrow-type promotion to unsigned int?
>
>> It's time for some defaults to change so that modern C is preferred,
>> and "implicit everything, hope the programmer got it right" requires
>> explicit action, *but it's still possible to do* for the 1970s
>> nostalgia fans.
> It is impossible for implicit int to lead to bugs.
...You're joking, right ? You can't possibly be seriously arguing this, 
you have to be kidding... right ?
>
>> If you want to believe that's the start of a slippery slope, that's
>> your choice. The nostalgia club can always fork gcc if necessary,
>> that's one of the great things about free software.
> I am not part of a nostalgia club, so you might as well stop using this
> label.  In courtrooms, the plantiffs may be precluded from using
> terminology that can mislead the jury.  This is more or less equivalent.
>
>> GCC has always taken backwards compatibility seriously. That doesn't
>> mean it is the prime directive and can never be violated, but it's
>> absolutely always considered. In this case, changing the default seems
>> appropriate to many people, including those who actually maintain gcc
>> and deal with the consequences of the current defaults.
> What consequences?  Really?
>
>> Do you have anything new to add other than repeating the same
>> arguments? We've heard them now, thanks.
> Yes, just these quotes from a former GCC maintainer:
>
>    In C, we cannot divide all user code into "right" and "wrong" in this
>    kind of simple way, and certainly not based on the ISO standard.  That
>    standard is just the decisions of a certain committee (which I was a
>    member of) about what cases conforming compilers should commit to
>    support.  We must not let ourselves start thinking that C code is
>    "wrong", just because it is not conforming ISO C code.
>
>    C programs use many cases that are not conforming, but do work.  This
>    will be true for as long as C is used, because changing it would
>    require major changes in the C language.
>
>    From time to time, there is a real *need* to make some of these cases
>    stop working, for the sake of some benefit that users want.  When this
>    happens, we should do it; the user community will accept it, because
>    they will see that it is being done for their sake.  Some will
>    grumble, but the users who appreciate the benefits will convince them.
>
>    But when there is no *need* to break these cases, when we can keep
>    them working fairly easily, we should keep them working.  If we break
>    them unnecessarily, we invite the legitimate anger of the users.
>
> and:
>
>    You are arguing for a position that rejects the very idea of making an
>    effort to keep old code working.  Your arguments support a general
>    conclusion that "If code is not unambiguously valid, it is better to
>    break the code than to keep it working."
>
>    This is not just a harsh policy, it is an explicit policy of being
>    harsh.  That is, it says, "Be harsh!  Choose the alternative that is
>    harsh!"  This is the opposite of the way we should treat our users.
>
>    I understand that your views are not based on sadism or cruelty; you
>    think that treating users harshly is better for them.  But your
>    motivation, like my motivation, is not the issue anyway.  To adopt a
>    policy of harshness towards people--no matter what justification is
>    offered for it--is treating them badly.  That is the wrong way to
>    treat the users.  We must not make GCC decisions based on a policy of
>    harshness.
>
>    I would like future GCC decisions to be based on the policy that
>    keeping old code working is a good thing to do, when it is practical
>    of course.
>
>    So if any argument leads to the conclusion that one should be harsh to
>    the users, please recognize where the argument is taking you, and
>    reject it on the grounds that it is a disguised policy of harshness.
>
>    In particular, if it is argued that a policy of kindness has a
>    disadvantage, and it turns out that the disadvantage is a consequence
>    of the fact that the users have been treated kindly, it is really a
>    disguised policy of harshness.
>
> It is sad that this mature attitude no longer seems to be prevalent
> among the current maintainership.

Re: More C type errors by default for GCC 14

[Po Lu]

Pedro Alves <pedro@palves.net> writes:

> Then write a wrapper script named "cc", and put that in the PATH:
>
>  $ cat cc
>  #!/bin/sh
>
>  exec /my/real/gcc -fwhatever "$@"
>
> Done.

And how many people are going to be forced to do this?

Though this is a good point: I suspect if such an option were actually
added, most sites would simply install such a script as `gcc', and as a
result the stricter behavior would not actually reach anyone.  Making it
pointless, wouldn't you say?

Re: More C type errors by default for GCC 14

[Po Lu]

Gabriel Ravier <gabravier@gmail.com> writes:

> It's "extra work" to add 10 characters to a Makefile, but normal to
> add random faulty declarations everywhere ? 

You're assuming that people are willing to edit Makefiles, which is all
kinds of pain, and then put up with a complete recompile of whatever
software is being built because CFLAGS changed.

> I could only imagine someone doing this if they're being either
> extremely uninformed, extremely restricted (e.g. no change to any
> configuration files, no pragmas to disable the errors and not even
> having 10 seconds to look up the correct function prototype) or
> deliberately obtuse.

Under time restrictions, or being extremely uninformed, yes.  These are
precisely the situations that many GCC users are under.

> Now you're the one playing with words. That, or you have a complete
> lack of understanding of extremely common English expressions, which
> you may want to work on as you will otherwise inevitably have large
> problems effectively communicating anything with people on this list.

That my response was so short should have made my point clear, right?
It's a tangent.  I don't claim to speak for anyone other than myself,
and Eli Schwartz implied that I was.

> The "definition of GCC" used here is in a more general sense, i.e. the
> GCC project and the people involved in it that would be considered
> generally representative of it.

But we're debating behavior of the C translator itself, and the
definition of that is clear: the code which comprises the C translator,
cc1, and its frontend, gcc.  What any person thinks, AFAIK, is not
really relevant.

> In fact, so far on this thread I've seen almost nobody on your side of
> the argument, save for a very few extremely loud people repeating the
> same arguments over and over.

From my perspective, I also see only a few extremely loud people
repeating the same arguments over and over.  But how many times have I
mentioned that?  The number of people in this thread is too small to
conclude anything from.

> So far I've seen only a single minor GCC contributor arguing the
> behavior should be kept as-is - pretty much everyone else agrees the
> behavior should be changed. In fact, I've talked to many people who
> are not currently posting in this thread, who consider that the
> default should be changed, and are watching in consternation as a few
> people appear to be trying to hold back the entire community with
> extremely bad defaults.

In this entire thread of long winded flames, I've not heard a single
reasonable attempt to explain the following points of contention:

  1. Why GCC gets to judge whether or not users' code is correct or not.

  2. How implicit function declarations are different from function
     declarations with no parameter specification, and why it is
     reasonable to make the former an error while allowing the latter.

     By extension, why implicit function declarations are ``always
     wrong'', as some people have been claiming.

     (Aside from, of course, that ``the Standard allows''.
      But the Standard also allows implicit function declarations and
      int.)

  3. How implicit int makes the meaning of a program unclear, in any
     way, with the exception of C2X and auto.  I have not ever seen auto
     explicitly used as a storage class specifier, so from my
     perspective that is not really a problem.

  4. Why people under various time or (mental) energy constraints will
     not simply insert the necessary declarations to pacify GCC, which
     will be as correct as the implicit declaration was.

> In the "C Extensions" section?

The `C Extensions' node is not the only document describing extensions
accompanying the translator.

> By the same line of argumentation, any accepts-invalid is actually not
> a bug and should instead be considered a documentation bug that should
> be fixed by altering the documentation rather than fixing the actual
> bug (given that you appear to consider that making GCC not accept code
> that it previously accepted by default is something that should never
> be done). I hope you understand that's not a reasonable line of
> argumentation.

No, because this is not a bug where GCC accepts invalid code in the
first place.  This is behavior which was explicitly introduced into GCC,
but not documented in a more appropriate location in the manual.

> To be honest, I'd be inclined to consider the current behavior a
> longstanding bug that's been wrongly considered to be a WONTFIX for
> many years, and that we're only now getting around to fixing, if you
> really want to go down this line of argumentation.

Where is the ticket/thread on {Bugzilla,gnu.gcc.bug,gcc-bugs}?  Anyway,
I've never argued anything to this effect.  In fact, I would be more
inclined to consider the decision to not consider this a bug the
decision that explicitly defined it as behavior of the C translator.

> Actually, now that I think about it, what are you actually trying to
> get from this conversation ? If you're unsatisfied with a lack of
> commitment from the maintainers to maintain a `-fpermissive` option
> indefinitely, it seems like you can't possibly be satisfied with the
> current situation, either. It seems like what you actually want is an
> eternal commitment from the GCC developers to never ever change the
> behavior of GCC ever in any way that could ever break any of your old
> broken code...

I don't want anything, seeing as I've been using GCC less and less over
the years (for this and other reasons.)  I'm just throwing in my two or
so cents.

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> This sounds like a "you" problem.

I don't write these Makefiles.  Others do.
It wasn't the problem of their authors before, so why should it be now?

Re: More C type errors by default for GCC 14

[Po Lu]

Gabriel Ravier <gabravier@gmail.com> writes:

> As somebody that spends a lot of time helping beginners, yes,
> constantly. I'd go as far as to say it's an error that seemingly
> everyone has made at least once.

Really?  And after making this mistake (and learning its solution), did
they continue to make the same mistake?

Because I don't see why it's a good idea to expect people who have just
begun learning C to immediately be able to write correct code.

BTW, please don't quote the parts of of an article which you are not
responding to.  Especially not excessively so, which you just did.

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Fri, 12 May 2023 at 14:54, Po Lu via Gcc <gcc@gcc.gnu.org> wrote:
> From my perspective, I also see only a few extremely loud people
> repeating the same arguments over and over.

Maybe stop then?

> But how many times have I
> mentioned that?  The number of people in this thread is too small to
> conclude anything from.

Maybe if you were quieter yourself you'd see more replies in favour
from different people:

https://gcc.gnu.org/pipermail/gcc/2023-May/241434.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241424.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241475.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241384.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241308.html

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Joseph Myers:

> On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>
>> That is not the case we are discussing, AFAIU.  Or at least no one has
>> yet explained why accepting those old K&R programs will adversely
>> affect the ability of GCC to compile C2x programs.
>
> At block scope,
>
>   auto x = 1.5;
>
> declares x to have type double in C2x (C++-style auto), but type int in 
> C89 (and is invalid for versions in between).  In this case, there is an 
> incompatible semantic change between implicit int and C++-style auto.  
> Giving an error before we make -std=gnu2x the default seems like a 
> particularly good idea, to further alert anyone who has been ignoring the 
> warnings about implicit int that semantics will change incompatibly.

Obviously makes sense to me.

> In cases where the standard requires a diagnostic, some are errors, some 
> are pedwarns-by-default or unconditional pedwarns, some are 
> pedwarns-if-pedantic - the choice depending on how suspicious the 
> construct in question is and whether it corresponds to a meaningful 
> extension (this is not making an automatic choice for every such situation 
> in the standard, it's a case-by-case judgement by maintainers).  By now, 
> the cases discussed in this thread are sufficiently suspicious - 
> sufficiently likely to result in unintended execution at runtime (not, of 
> course, reliably detected because programs with such dodgy code are very 
> unlikely to have thorough automated tests covering all their code) - that 
> is it in the interests of users for them to be errors by default (for C99 
> and later modes, in the cases that were valid in C89).

Just to recap, those are controlled by
-Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
-Wincompatible-pointer-types, roughly in increasing order of
compatibility impact with old sources.

> It might also make sense to review other pedwarns-by-default and 
> unconditional pedwarns to consider if any of those should be errors by 
> default, though I suspect most of those are less significant.

I went through the pedwarn calls in the C front end.

First, these two appear to be genuine bugs:

  Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826>

  Pointer/integer mismatch in ?: not covered by -Wint-conversion
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109827

Maybe the latter more so than the former.  These create pointer
values, so they seem problematic.

There are related coverage gaps for comparison operators for the more
specific -W… options:

  pedwarn (location, 0, "comparison of distinct pointer types lacks a cast");
  pedwarn (location, OPT_Wpedantic, 
           "ordered comparison of pointer with integer zero");
  pedwarn (location, 0, "comparison between pointer and integer");

These expressions do not create pointer values, so maybe they are less
likely to introduce bugs?  But they are type errors in standard C.
(Clang has separate warnings for those, -Wcompare-distinct-pointer-types.)


Moving on, this seems to be a good candidate for an error:

  pedwarn (input_location, 0, "parameter names (without types) in "
           "function declaration");

The reason is that

  void f (uint3_t);

is a function declaration without a prototype, which is very likely
not what is intended.  The error diagnostic could also provide a
spelling hint for the type.


We may not need to do anything for this one (except removing cascading
errors) because I think this is only reachable when an implicit int is
involved:

  pedwarn (here, 0, "data definition has no type or storage class");


(Slightly unrelated because it's a purely syntactic issue.  It's about
designated initaliziers of the form “{ a[0] 1 }”:

  pedwarn (c_parser_peek_token (parser)->location, OPT_Wpedantic,
           "obsolete use of designated initializer without %<=%>");

Unclear whether we still need to support that, but also harmless, I
guess.)


This one seems to be hack to support obsolete wait function usage.  We
probably don't need it any more because the union wait was removed
from glibc 2.24, and the function prototypes in glibc are now more
standard.  The union wait type was deprecated in the early 90s.

  /* Given  wait (union {union wait *u; int *i} *)
     and  wait (union wait *),
     prefer  union wait *  as type of parm.  */
   pedwarn (input_location, OPT_Wpedantic,
            "function types not truly compatible in ISO C")

And furher below in c-typeck.cc:

  /* Allow  wait (union {union wait *u; int *i} *)
     and  wait (union wait *)  to be compatible.  */

I think it should be safe to error for these by default.


I couldn't figure out what these warnings are about:

  pedwarn (input_location, OPT_Wpedantic,
           "function types not truly compatible in ISO C");
  pedwarn (location, OPT_Wpedantic, "types are not quite compatible");


This seems to be mainly for &*p if p is of type void *:

  warning_at (loc, 0, "dereferencing %<void *%> pointer");
  pedwarn (location, 0, "taking address of expression of type %<void%>");

Rather hideous, but maybe harmless in the grand scheme of things?


One rather large set of pedwarns concerns qualifier mismatches.  I
believe this is about technically undefined behavior, so maybe the
warning is not about things that are entirely harmless.  Implicitly
dropping const-ness from pointers could cause crashes at a later
stage, so more rigorous errors could point at the location of the
actual mistake.  On the other hand, C programs aiming for full
const-correctness are quite rare.  Adding all those casts for things
like

  volatile int x[4];
  memset (x, 0, sizeof (x));

would be quite cumbersome, too.  So I'm not sure what to do about
these.

Then there is -Wpointer-sign.  The Linux kernel really dislikes that
warning, so we would want a mechanism to control that separately.
Again not sure what to do about those.


This sone seems to be a good candidate for additional errors, though:

  warned_here = pedwarn
    (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
     "%<return%> with no value, in function returning non-void");

It's a clear type volation that can lead to obscure bugs.  Maybe the
converse as well.


In summary, all these seems to be good candidates for errors by default:

* int-conversion as errors (already raised separately
* -Wint-conversion for ?:
* parameter names in non-prototype function declarations
* the union wait function pointer compatibility kludge
* return-with-out-value for non-void functions
* -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

This are more “maybe“:

* incompatible-pointer-types as errors (already raised separately)
* int-conversion and incompatible-pointer-types in comparisons
* return with value in a function returning void
* dereferencing void *
* taking the address of void
* "function types not truly compatible in ISO C"
  and "types are not quite compatible" (depending on what they actually mean)
* qualifier mismatches (may need separate opt-out)
* sign mismatches in pointers (definitely needs separate opt-out)

I can do experiments on the Fedora code base in the coming weeks for
at least a subset of those.  The second list likely has a few with
quite high cost for us.  I suspect even incompatible-pointer-types is
problematic in that regard.  The first list seems more manageable,
although int-conversion is also a fairly big work item (and I need to
find a way to cut down the number of false positives from the tester).

Re: More C type errors by default for GCC 14

[Jason Merrill]

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc <gcc@gcc.gnu.org> wrote:
> Yes, just these quotes from a former GCC maintainer:
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.

Absolutely.  The debate is really over the degree of "need" and the
degree of "break".

The proposal argues that the need is to help developers using GCC
avoid a common class of wrong-code bugs that have gotten worse with
the rise of platforms with 64-bit pointers and 32-bit int, and even
more with the adoption of position-independent executables as a
security measure.

The "break" is asking affected legacy code to adjust build flags, if
they don't want to adjust their code.

Note that some such legacy code does in fact need to be fixed to work
properly on modern systems, e.g.
https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray

Certainly there are people in both camps with valid perspectives, as
Florian pointed out early in his initial email.  Previously, we've
leaned toward the second camp for these particular issues.  But the
problem above strengthens the case of the first camp. And the
dwindling amount of affected code weakens the case of the second camp.
And so the proposal suggests that we change the default behavior.

As a compromise, it should be possible to error by default only in
cases where the implicit int (including as a return value) is either
the source or target of a non-value-preserving conversion, as those
are very likely to be bugs.  That seems desirable for both camps.

A simpler change to catch this particular bug would be to make
-Wint-conversion an error by default iff the sizes differ.

(Incidentally, for the first camp, it seems desirable to have a flag
to upgrade all currently enabled pedwarns to errors without also
enabling pedwarns that depend on -pedantic/-Wpedantic;
-pedantic-errors does both; -Werror=pedantic makes only the latter set
errors, which seems unlikely to be useful to anyone.)

Jason

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Florian Weimer:

> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

I think we have another problem.

We do not warn by default for:

  int x;
  unsigned *p;

  p = &x;

Isn't that a conformance issue because the pointers are incompatible,
requiring a diagnostic?

Furthermore, Unlike the char case, this tends to introduce
strict-aliasing violations, so there is a good reason to treat this
variant as an error (even if we would only warn for char * and
unsigned char *).

Re: More C type errors by default for GCC 14

[Gabriel Ravier]

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

On 5/12/23 19:52, Florian Weimer wrote:
> * Florian Weimer:
>
>> In summary, all these seems to be good candidates for errors by default:
>>
>> * int-conversion as errors (already raised separately
>> * -Wint-conversion for ?:
>> * parameter names in non-prototype function declarations
>> * the union wait function pointer compatibility kludge
>> * return-with-out-value for non-void functions
>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
> I think we have another problem.
>
> We do not warn by default for:
>
>    int x;
>    unsigned *p;
>
>    p = &x;
>
> Isn't that a conformance issue because the pointers are incompatible,
> requiring a diagnostic?
>
> Furthermore, Unlike the char case, this tends to introduce
> strict-aliasing violations, so there is a good reason to treat this
> variant as an error (even if we would only warn for char * and
> unsigned char *).

Isn't this allowed by the standard ? 6.5.7. Expressions states:
 > An object shall have its stored value accessed only by an lvalue 
expression that has one of thefollowing types:[...] - a type that is the 
signed or unsigned type corresponding to the effective type of the object

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Gabriel Ravier:

> On 5/12/23 19:52, Florian Weimer wrote:
>> * Florian Weimer:
>>
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>> I think we have another problem.
>>
>> We do not warn by default for:
>>
>>    int x;
>>    unsigned *p;
>>
>>    p = &x;
>>
>> Isn't that a conformance issue because the pointers are incompatible,
>> requiring a diagnostic?
>>
>> Furthermore, Unlike the char case, this tends to introduce
>> strict-aliasing violations, so there is a good reason to treat this
>> variant as an error (even if we would only warn for char * and
>> unsigned char *).
>
> Isn't this allowed by the standard ? 6.5.7. Expressions states:
>  > An object shall have its stored value accessed only by an lvalue 
> expression that has one of thefollowing types:[...] - a type that is the 
> signed or unsigned type corresponding to the effective type of the object

Ahh, so no strict aliasing violation at least.

Still I think we are required to diagnose the constraint violation in
the pointer assignment.  (Cerberus quotes C11 §6.5.16.1#1, bullet 3
and 4 as violation.)

Re: More C type errors by default for GCC 14

[Alexander Monakov]

On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote:

> On 5/12/23 19:52, Florian Weimer wrote:
> > I think we have another problem.
> >
> > We do not warn by default for:
> >
> >    int x;
> >    unsigned *p;
> >
> >    p = &x;
> >
> > Isn't that a conformance issue because the pointers are incompatible,
> > requiring a diagnostic?
> >
> > Furthermore, Unlike the char case, this tends to introduce
> > strict-aliasing violations, so there is a good reason to treat this
> > variant as an error (even if we would only warn for char * and
> > unsigned char *).
> 
> Isn't this allowed by the standard ? 6.5.7. Expressions states:
> > An object shall have its stored value accessed only by an lvalue 
> expression that has one of thefollowing types:[...] - a type that is the
> signed or unsigned type corresponding to the effective type of the object

The standard allows aliasing, but not assigning pointers without a cast.

This is valid:

  unsigned x;

  int *p = (void *)&x;

  *p = 0;

This is not valid (constraint violation):

  unsigned x;

  int *p = &x;

In GCC this is diagnosed under -Wpointer-sign:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892

Alexander

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Alexander Monakov:

> This is not valid (constraint violation):
>
>   unsigned x;
>
>   int *p = &x;
>
> In GCC this is diagnosed under -Wpointer-sign:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892

Thanks for the reference.  I filed:

  -Wpointer-sign must be enabled by default
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836>

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Fri, 12 May 2023, Florian Weimer wrote:

> This sone seems to be a good candidate for additional errors, though:
> 
>   warned_here = pedwarn
>     (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>      "%<return%> with no value, in function returning non-void");
> 
> It's a clear type volation that can lead to obscure bugs.  Maybe the
> converse as well.

This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
otherwise it's a warning).  The converse is unconditionally invalid 
(though the case where the returned expression from the function with void 
return type itself has void type is valid in C++ and only a 
pedwarn-if-pedantic for C; that case is a reasonable extension).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: More C type errors by default for GCC 14

[Jason Merrill]

On Fri, May 12, 2023 at 11:03 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Joseph Myers:
>
> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> >
> >> That is not the case we are discussing, AFAIU.  Or at least no one has
> >> yet explained why accepting those old K&R programs will adversely
> >> affect the ability of GCC to compile C2x programs.
> >
> > At block scope,
> >
> >   auto x = 1.5;
> >
> > declares x to have type double in C2x (C++-style auto), but type int in
> > C89 (and is invalid for versions in between).  In this case, there is an
> > incompatible semantic change between implicit int and C++-style auto.
> > Giving an error before we make -std=gnu2x the default seems like a
> > particularly good idea, to further alert anyone who has been ignoring the
> > warnings about implicit int that semantics will change incompatibly.
>
> Obviously makes sense to me.

Agreed.  But we could safely continue to accept

  static x = 42;

or even

  auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not

We might make -Wimplicit-int an error by default only if the
initializer has a type other than 'int'.

> > In cases where the standard requires a diagnostic, some are errors, some
> > are pedwarns-by-default or unconditional pedwarns, some are
> > pedwarns-if-pedantic - the choice depending on how suspicious the
> > construct in question is and whether it corresponds to a meaningful
> > extension (this is not making an automatic choice for every such situation
> > in the standard, it's a case-by-case judgement by maintainers).  By now,
> > the cases discussed in this thread are sufficiently suspicious -
> > sufficiently likely to result in unintended execution at runtime (not, of
> > course, reliably detected because programs with such dodgy code are very
> > unlikely to have thorough automated tests covering all their code) - that
> > is it in the interests of users for them to be errors by default (for C99
> > and later modes, in the cases that were valid in C89).
>
> Just to recap, those are controlled by
> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
> -Wincompatible-pointer-types, roughly in increasing order of
> compatibility impact with old sources.

What would the impact be of making -Wint-conversion an error by
default only if the types are different sizes?

Jason

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Joseph Myers:

> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> This sone seems to be a good candidate for additional errors, though:
>> 
>>   warned_here = pedwarn
>>     (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>>      "%<return%> with no value, in function returning non-void");
>> 
>> It's a clear type volation that can lead to obscure bugs.  Maybe the
>> converse as well.
>
> This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
> otherwise it's a warning).

Ahh, I see now, this is required for making “return;” work in
functions returning an implied int type.  So it's tied to implicit-int
removal.  I'm going to add checking this to a future run.

> The converse is unconditionally invalid 
> (though the case where the returned expression from the function with void 
> return type itself has void type is valid in C++ and only a 
> pedwarn-if-pedantic for C; that case is a reasonable extension).

Agreed.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Jason Merrill:

> On Fri, May 12, 2023 at 11:03 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * Joseph Myers:
>>
>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>> >
>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>> >> yet explained why accepting those old K&R programs will adversely
>> >> affect the ability of GCC to compile C2x programs.
>> >
>> > At block scope,
>> >
>> >   auto x = 1.5;
>> >
>> > declares x to have type double in C2x (C++-style auto), but type int in
>> > C89 (and is invalid for versions in between).  In this case, there is an
>> > incompatible semantic change between implicit int and C++-style auto.
>> > Giving an error before we make -std=gnu2x the default seems like a
>> > particularly good idea, to further alert anyone who has been ignoring the
>> > warnings about implicit int that semantics will change incompatibly.
>>
>> Obviously makes sense to me.
>
> Agreed.  But we could safely continue to accept
>
>   static x = 42;
>
> or even
>
>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not
>
> We might make -Wimplicit-int an error by default only if the
> initializer has a type other than 'int'.

Based on what I saw fixing Fedora, these cases are not very common.
Sure, sometimes common program such as valgrind have an instance
<https://bugs.kde.org/show_bug.cgi?id=462007>, but that's really an
exception.

Implicit int is common as the return type of main (especially in
autoconf tests), and due to a missing declaration list entry of an
old-style function definition.  The main case could be treated as an
exception.  The old-style function definition case is a common source
of bugs and therefore worth fixing.  The addition of unnamed function
parameters as an extension actually created a new class of bugs here
(a typo in the type name of a single unnamed parameter results in an
old-style function definition by accident).

>> > In cases where the standard requires a diagnostic, some are errors, some
>> > are pedwarns-by-default or unconditional pedwarns, some are
>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>> > construct in question is and whether it corresponds to a meaningful
>> > extension (this is not making an automatic choice for every such situation
>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>> > the cases discussed in this thread are sufficiently suspicious -
>> > sufficiently likely to result in unintended execution at runtime (not, of
>> > course, reliably detected because programs with such dodgy code are very
>> > unlikely to have thorough automated tests covering all their code) - that
>> > is it in the interests of users for them to be errors by default (for C99
>> > and later modes, in the cases that were valid in C89).
>>
>> Just to recap, those are controlled by
>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>> -Wincompatible-pointer-types, roughly in increasing order of
>> compatibility impact with old sources.
>
> What would the impact be of making -Wint-conversion an error by
> default only if the types are different sizes?

From a distribution perspective, it does not change anything because
we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
doesn't require all builds to succeed before the new package can be
installed, but given that the primary targets are 64 bit, I don't
think a restricted -Wint-conversion error would be much of a
simplification.  The target-dependent nature of the warning is
probably more confusing.

Re: More C type errors by default for GCC 14

[Sam James]

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


Florian Weimer <fw@deneb.enyo.de> writes:

> * Jason Merrill:
>
>> On Fri, May 12, 2023 at 11:03 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>>>
>>> * Joseph Myers:
>>>
>>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>>> >
>>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>>> >> yet explained why accepting those old K&R programs will adversely
>>> >> affect the ability of GCC to compile C2x programs.
>>> >
>>> > At block scope,
>>> >
>>> >   auto x = 1.5;
>>> >
>>> > declares x to have type double in C2x (C++-style auto), but type int in
>>> > C89 (and is invalid for versions in between).  In this case, there is an
>>> > incompatible semantic change between implicit int and C++-style auto.
>>> > Giving an error before we make -std=gnu2x the default seems like a
>>> > particularly good idea, to further alert anyone who has been ignoring the
>>> > warnings about implicit int that semantics will change incompatibly.
>>>
>>> Obviously makes sense to me.
>>
>> Agreed.  But we could safely continue to accept
>>
>>   static x = 42;
>>
>> or even
>>
>>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not
>>
>> We might make -Wimplicit-int an error by default only if the
>> initializer has a type other than 'int'.
>
> Based on what I saw fixing Fedora, these cases are not very common.
> Sure, sometimes common program such as valgrind have an instance
> <https://bugs.kde.org/show_bug.cgi?id=462007>, but that's really an
> exception.
>
> Implicit int is common as the return type of main (especially in
> autoconf tests), and due to a missing declaration list entry of an
> old-style function definition.  The main case could be treated as an
> exception.  The old-style function definition case is a common source
> of bugs and therefore worth fixing.  The addition of unnamed function
> parameters as an extension actually created a new class of bugs here
> (a typo in the type name of a single unnamed parameter results in an
> old-style function definition by accident).
>
>>> > In cases where the standard requires a diagnostic, some are errors, some
>>> > are pedwarns-by-default or unconditional pedwarns, some are
>>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>>> > construct in question is and whether it corresponds to a meaningful
>>> > extension (this is not making an automatic choice for every such situation
>>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>>> > the cases discussed in this thread are sufficiently suspicious -
>>> > sufficiently likely to result in unintended execution at runtime (not, of
>>> > course, reliably detected because programs with such dodgy code are very
>>> > unlikely to have thorough automated tests covering all their code) - that
>>> > is it in the interests of users for them to be errors by default (for C99
>>> > and later modes, in the cases that were valid in C89).
>>>
>>> Just to recap, those are controlled by
>>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>>> -Wincompatible-pointer-types, roughly in increasing order of
>>> compatibility impact with old sources.
>>
>> What would the impact be of making -Wint-conversion an error by
>> default only if the types are different sizes?
>
> From a distribution perspective, it does not change anything because
> we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
> doesn't require all builds to succeed before the new package can be
> installed, but given that the primary targets are 64 bit, I don't
> think a restricted -Wint-conversion error would be much of a
> simplification.  The target-dependent nature of the warning is
> probably more confusing.

I don't see us really gaining anything from restricting it. Like you
said, the cases in the wild are actually all of the same "class".

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

Re: More C type errors by default for GCC 14

[Sam James]

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


Florian Weimer <fw@deneb.enyo.de> writes:

> [...]
> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>
> This are more “maybe“:
>
> * incompatible-pointer-types as errors (already raised separately)
> * int-conversion and incompatible-pointer-types in comparisons
> * return with value in a function returning void

-Wreturn-type tends to bite people with C++. Obviously the behaviour
is different for C, but it's a serious code smell. I've been playing
with it for C for a while and I don't get that many hits with it of
this type.

> * dereferencing void *
> * taking the address of void

I think I've seen these but they've been accompanied by other issues.

> * "function types not truly compatible in ISO C"
>   and "types are not quite compatible" (depending on what they actually mean)
> * qualifier mismatches (may need separate opt-out)

This has been common for func. ptrs. but not too bad. I haven't
got any data on other cases but am a bit worried about how noisy it'll
be for those.

> * sign mismatches in pointers (definitely needs separate opt-out)
>

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

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> [...]
>> In summary, all these seems to be good candidates for errors by default:
>>
>> * int-conversion as errors (already raised separately
>> * -Wint-conversion for ?:
>> * parameter names in non-prototype function declarations
>> * the union wait function pointer compatibility kludge
>> * return-with-out-value for non-void functions
>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>
>> This are more “maybe“:
>>
>> * incompatible-pointer-types as errors (already raised separately)
>> * int-conversion and incompatible-pointer-types in comparisons
>> * return with value in a function returning void
>
> -Wreturn-type tends to bite people with C++.

Sorry, what do you mean?

Re: More C type errors by default for GCC 14

[Sam James]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Sam James:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> [...]
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>>
>>> This are more “maybe“:
>>>
>>> * incompatible-pointer-types as errors (already raised separately)
>>> * int-conversion and incompatible-pointer-types in comparisons
>>> * return with value in a function returning void
>>
>> -Wreturn-type tends to bite people with C++.
>
> Sorry, what do you mean?

Falling off the end of a function in C++ is UB and people fall
victim to it often, but in C, it's only UB if you try to use
its return value.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
example of many.

What I meant was: I see this a lot in C++ and sometimes in C
but it's usually trivial to fix, even if it's less harmful
for some of the instances.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Sam James:
>>
>>> Florian Weimer <fw@deneb.enyo.de> writes:
>>>
>>>> [...]
>>>> In summary, all these seems to be good candidates for errors by default:
>>>>
>>>> * int-conversion as errors (already raised separately
>>>> * -Wint-conversion for ?:
>>>> * parameter names in non-prototype function declarations
>>>> * the union wait function pointer compatibility kludge
>>>> * return-with-out-value for non-void functions
>>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>>>
>>>> This are more “maybe“:
>>>>
>>>> * incompatible-pointer-types as errors (already raised separately)
>>>> * int-conversion and incompatible-pointer-types in comparisons
>>>> * return with value in a function returning void
>>>
>>> -Wreturn-type tends to bite people with C++.
>>
>> Sorry, what do you mean?
>
> Falling off the end of a function in C++ is UB and people fall
> victim to it often, but in C, it's only UB if you try to use
> its return value.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
> example of many.
>
> What I meant was: I see this a lot in C++ and sometimes in C
> but it's usually trivial to fix, even if it's less harmful
> for some of the instances.

Ohh, I was thinking just about the -Wreturn-type issues for return
statements (value vs no value), not “control reaches end of non-void
function”.  That's a separate issue, and yes, it's more confusing for
C++ due to undefined behavior back-propagation within the same
function.

Re: More C type errors by default for GCC 14

[Po Lu]

Gabriel Ravier <gabravier@gmail.com> writes:

> ...You're joking, right ? You can't possibly be seriously arguing
> this, you have to be kidding... right ?

No, I'm not.  The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.
There's absolutely nothing ambiguous about it whatsoever:

  register i;
  extern   limit, *k, do_some_computation ();

  for (i = 0; i < limit; ++i)
    k[i] = do_some_computation (i);

Please try to prove me wrong.

Re: More C type errors by default for GCC 14

[Thomas Koenig]

On 13.05.23 02:45, Po Lu via Gcc wrote:
> Gabriel Ravier <gabravier@gmail.com> writes:
> 
>> ...You're joking, right ? You can't possibly be seriously arguing
>> this, you have to be kidding... right ?
> 
> No, I'm not.  The meaning of a variable declaration with only a storage
> class specifier is extremely clear: the type of the variable is `int'.

C99, 6.7.2, "Type specifiers"

# Constraints

# At least one type specifier shall be given in the declaration
# specifiers in each declaration, and in the specifier-qualifier
# list in each struct declaration and type name.

> There's absolutely nothing ambiguous about it whatsoever:

In C99 and onwards, this is an error (a violation of a "shall"
directive).

>    register i;
>    extern   limit, *k, do_some_computation ();
> 
>    for (i = 0; i < limit; ++i)
>      k[i] = do_some_computation (i);
> 
> Please try to prove me wrong.

Happy to oblige.

Re: More C type errors by default for GCC 14

[Po Lu]

Thomas Koenig <tkoenig@netcologne.de> writes:

> C99, 6.7.2, "Type specifiers"
>
> # Constraints
>
> # At least one type specifier shall be given in the declaration
> # specifiers in each declaration, and in the specifier-qualifier
> # list in each struct declaration and type name.

And?

> In C99 and onwards, this is an error (a violation of a "shall"
> directive).

There are no ``errors'' in Standard C (with the possible exception of
the #error preprocessing directive), only constraint and syntax rule
violations.  Such violations are required to generate diagnostic
messages, after which the behavior of the translator ceases to be
defined by the Standard, but GNU C defines it to mean that the type is
int.

Nor does GCC conform to the Standard by default: while it is okay for a
conforming implementation to translate programs relying on implicit int,
as there is no way doing so will alter the behavior of any strictly
conforming program, it is not okay to reserve keywords such as `asm'.

The following strictly conforming program is thus not acceptable to GCC,
unless GCC is operating in standards-conformance mode:

  int
  main (argc, argv)
  int argc;
  char **argv;
  {
    int asm;
    return asm = 0;
  }

which shows that debating features based on the Standard is entirely
pointless, as the Standard allows implementations to provide almost
anything it prohibits.

So I ask you again: what is unclear about declarations which are
implicitly int, in a way that is likely to cause program errors?

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/12/23 8:45 PM, Po Lu wrote:
> Gabriel Ravier <gabravier@gmail.com> writes:
> 
>> ...You're joking, right ? You can't possibly be seriously arguing
>> this, you have to be kidding... right ?
> 
> No, I'm not.  The meaning of a variable declaration with only a storage
> class specifier is extremely clear: the type of the variable is `int'.
> There's absolutely nothing ambiguous about it whatsoever:


Quoting my previous reply on the topic.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.

You are of the opinion that "GCC currently behaves a certain way when
compiling the code" means that the behavior is documented and specified
as a "C Extension" for the GNUC language dialect.

You've provided some excuses like "C++ is a valid language for writing
documentation in, and the HTML docs are lacking", but your arguments are
not convincing.

GCC has formal documentation. It is written in HTML. If it is lacking,
then the only valid move is to improve the HTML documentation and then
abide by it. In the absence of documentation, all behavior is, well,
"undocumented", which ***definitely*** means it isn't a formal GNUC
language dialect extension.

You can stop arguing your opinions based on what running gcc or g++
produces in the form of machine code. What gcc or g++ produces in the
form of machine code is not guaranteed even across bugfix releases --
your only guarantee is that if it is documented in the ISO standards
documents or in the GCC html manual, the produced machine code shall be
in accordance with what the documentation says it shall do.

Undefined and undocumented behavior is not a language extension. It is
undefined and undocumented behavior. You may feel free to take an exact
GCC release (source or binary), analyze it, reverse-engineer it, or
verify that it does what you want it to do, and then trust that those
undefined and undocumented behaviors are ***benevolent***, but that
doesn't cause it to be defined and documented, and your trust will, if
you are wise, depend on you pinning an exact source code commit of the
compiler. Do not depend on bugfix releases of GCC to preserve your
undocumented semantics. They may or they may not, but if they don't,
it's not a GCC bug, because it is ***undocumented***.

...

So in answer to your question, the meaning of such a variable
declaration is very much unclear -- C specifies one thing, GNUC doesn't
specify *anything*, and actually executing the gcc compiler frontend
tool will do... something.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/13/23 1:53 AM, Po Lu wrote:
> There are no ``errors'' in Standard C (with the possible exception of
> the #error preprocessing directive), only constraint and syntax rule
> violations.  Such violations are required to generate diagnostic
> messages, after which the behavior of the translator ceases to be
> defined by the Standard, but GNU C defines it to mean that the type is
> int.


GNU C does not define any such thing. It may happen to turn out that
way, but that is not the same as defining its behavior.


> Nor does GCC conform to the Standard by default: while it is okay for a
> conforming implementation to translate programs relying on implicit int,
> as there is no way doing so will alter the behavior of any strictly
> conforming program, it is not okay to reserve keywords such as `asm'.
> 
> The following strictly conforming program is thus not acceptable to GCC,
> unless GCC is operating in standards-conformance mode:
> 
>   int
>   main (argc, argv)
>   int argc;
>   char **argv;
>   {
>     int asm;
>     return asm = 0;
>   }
> 
> which shows that debating features based on the Standard is entirely
> pointless, as the Standard allows implementations to provide almost
> anything it prohibits.


Sure, all I have to do is tell GCC to act like a C compiler.


$ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $?
/tmp/po.c: In function ‘main’:
/tmp/po.c:2:3: warning: old-style function definition
[-Wold-style-definition]
    2 |   main (argc, argv)
      |   ^~~~
0


But I don't understand what point you are trying to make, anyway. The
Standard allows, but does not require, implementations to do many things
if it so chooses. GNUC takes advantage of this when operating in GNUC
mode, when also documenting GNUC features in the HTML docs.


What does this have to do with implicit-int, which is a constraint
violation? Where in the GNUC html documentation does it say that
constraint violations applied to Type specifiers have been carved out as
a GNUC extension?

It's not a GNUC extension, you cannot assume it will work. It might work
anyway, but that's a matter of luck.


> So I ask you again: what is unclear about declarations which are
> implicitly int, in a way that is likely to cause program errors?

It is unclear why you are overly focused on implicit-int, to be honest.

But your arguments in favor of implicit-int aren't very compelling either.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Quoting my previous reply on the topic.
>
> Until everyone is on the same page as you about whether these are GNUC
> extensions, this conversation will go nowhere.
>
> You are of the opinion that "GCC currently behaves a certain way when
> compiling the code" means that the behavior is documented and specified
> as a "C Extension" for the GNUC language dialect.

Yes, by the definition of ``extension'' used by everyone except you.

> You've provided some excuses like "C++ is a valid language for writing
> documentation in, and the HTML docs are lacking", but your arguments are
> not convincing.
>
> GCC has formal documentation. It is written in HTML. If it is lacking,
> then the only valid move is to improve the HTML documentation and then
> abide by it. In the absence of documentation, all behavior is, well,
> "undocumented", which ***definitely*** means it isn't a formal GNUC
> language dialect extension.

GCC documentation is written in HTML? That's news to me.  I always
thought it was written in Texinfo.

> You can stop arguing your opinions based on what running gcc or g++
> produces in the form of machine code. What gcc or g++ produces in the
> form of machine code is not guaranteed even across bugfix releases --
> your only guarantee is that if it is documented in the ISO standards
> documents or in the GCC html manual, the produced machine code shall be
> in accordance with what the documentation says it shall do.

Generated machine code, really?  Not long-standing and observable
behavior of the translator itself, as has been re-iterated over and over
again?

> Undefined and undocumented behavior is not a language extension. It is
> undefined and undocumented behavior.

But when it becomes defined by the translator, in a precise way, it
becomes an extension to the Standard.

> You may feel free to take an exact GCC release (source or binary),
> analyze it, reverse-engineer it, or verify that it does what you want
> it to do, and then trust that those undefined and undocumented
> behaviors are ***benevolent***, but that doesn't cause it to be
> defined and documented, and your trust will, if you are wise, depend
> on you pinning an exact source code commit of the compiler. Do not
> depend on bugfix releases of GCC to preserve your undocumented
> semantics. They may or they may not, but if they don't, it's not a GCC
> bug, because it is ***undocumented***.

GCC does not implement its documentation.  The documentation is supposed
to describe (_not_ specify) how GCC behaves, and when the documentation
is wrong or contains omissions, the documentation will have to be fixed.
Not the compiler itself.

And it's not just GCC.  Almost all programs work this way.

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> GNU C does not define any such thing. It may happen to turn out that
> way, but that is not the same as defining its behavior.

It is.

>> Nor does GCC conform to the Standard by default: while it is okay for a
>> conforming implementation to translate programs relying on implicit int,
>> as there is no way doing so will alter the behavior of any strictly
>> conforming program, it is not okay to reserve keywords such as `asm'.
>> 
>> The following strictly conforming program is thus not acceptable to GCC,
>> unless GCC is operating in standards-conformance mode:
>> 
>>   int
>>   main (argc, argv)
>>   int argc;
>>   char **argv;
>>   {
>>     int asm;
>>     return asm = 0;
>>   }
>> 
>> which shows that debating features based on the Standard is entirely
>> pointless, as the Standard allows implementations to provide almost
>> anything it prohibits.
>
>
> Sure, all I have to do is tell GCC to act like a C compiler.
>
>
> $ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $?
> /tmp/po.c: In function ‘main’:
> /tmp/po.c:2:3: warning: old-style function definition
> [-Wold-style-definition]
>     2 |   main (argc, argv)
>       |   ^~~~
> 0

No, all you have to do is to tell GNU CC to compile Standard C.  But
what's being debated here is the behavior of GNU CC when translating
both Standard C and GNU C, so your demonstration is almost completely
pointless.

Btw, try to compile any program using inline assembler, and you will
quickly find out how many programs depend on the (gasp!) non-conformant
behavior of GNU C.

> But I don't understand what point you are trying to make, anyway. The
> Standard allows, but does not require, implementations to do many things
> if it so chooses. GNUC takes advantage of this when operating in GNUC
> mode, when also documenting GNUC features in the HTML docs.

[...]

> What does this have to do with implicit-int, which is a constraint
> violation? Where in the GNUC html documentation does it say that
> constraint violations applied to Type specifiers have been carved out as
> a GNUC extension?

As I said, what the Info documentation does not say is completely
irrelevant.  I might as well ask you: where in (gcc)C Extensions is it
said that the documentation describes each and every extension and
aspect of GNU C?

The documentation is supposed to describe the behavior of the
translator, not to specify it.

> It's not a GNUC extension, you cannot assume it will work. It might work
> anyway, but that's a matter of luck.

It _is_, regardless of what you might say.

> It is unclear why you are overly focused on implicit-int, to be honest.

Because there is a point to be made for discouraging implicit function
declarations.  Certainly not enough to make them errors in GNU C, but
enough to justify their obsolescence in the ANSI Standard.

There is none whatsoever for discouraging implicit int.  Its
obsolescence and later removal was simply the act of a overzealous
Committee, deviating too far from its task of standardizing existing
practice.

> But your arguments in favor of implicit-int aren't very compelling either.

Tell me how?

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/14/23 1:28 AM, Po Lu wrote:
>> GCC has formal documentation. It is written in HTML. If it is lacking,
>> then the only valid move is to improve the HTML documentation and then
>> abide by it. In the absence of documentation, all behavior is, well,
>> "undocumented", which ***definitely*** means it isn't a formal GNUC
>> language dialect extension.
> 
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.


Does this mean you've conceded the point, and no longer think it is
written in C++?

:)


>> You can stop arguing your opinions based on what running gcc or g++
>> produces in the form of machine code. What gcc or g++ produces in the
>> form of machine code is not guaranteed even across bugfix releases --
>> your only guarantee is that if it is documented in the ISO standards
>> documents or in the GCC html manual, the produced machine code shall be
>> in accordance with what the documentation says it shall do.
> 
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?


You are correct in reading my sentence, that is indeed what I said.

Aside: you have reiterated "the behavior of the translator itself" over
and over again, but it hasn't been generally reiterated, or even iterated.


>> Undefined and undocumented behavior is not a language extension. It is
>> undefined and undocumented behavior.
> 
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.


Repeating this statement won't make it true.


>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.


In fact, lots and lots and lots of programs do indeed operate such that
the documentation specifies how the program shall behave, and when the
program fails to behave in the manner in which it is documented to
behave, the program shall be fixed.

We call these failures to behave according to the documentation,


Bugs.


Occasionally it is also called specification-driven development.

...

In cases where the documentation says nothing at all, for good or ill,
the behavior of the program is undefined -- users cannot rely on it, for
they cannot know what is intended and what is not intended -- in this
case, the intended behavior must be defined, documented, and
implemented, and "the program currently does X" gets one vote out of
many and is not guaranteed to get its way.

Very often in such cases the best user-serving thing to do is to define
the behavior as "shall not be used, and for legacy reasons if you use it
it will continue to do X but raise a warning telling you that you are
required to stop depending on it" and possibly even "it may disappear in
semver version YYY".

Sound familiar? A bit like GCC triggering a warning, telling you that
what you're doing is bad and should not be relied on?

But GCC isn't dropping support for it in semver version anything, just
guarding its use behind an opt-in flag.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz]

On 5/14/23 1:28 AM, Po Lu wrote:
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.


But perhaps we can solve this argument.

Please submit a bug report at https://gcc.gnu.org/bugzilla/ to report
that the documentation is wrong or contains omissions, and has to be fixed.

Point out that the C Extensions page omits the documentation on implicit
function declarations and implicit ints. Consider including a patch that
updates https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html to mention
them as well.

If and when this page is updated to document that the compiler's
behavior with these features constitutes a C Extension, then I will
withdraw every comment I have made in this thread.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Sun, 14 May 2023, 06:28 Po Lu, <luangruo@yahoo.com> wrote:

> Eli Schwartz <eschwartz93@gmail.com> writes:
>
> > Quoting my previous reply on the topic.
> >
> > Until everyone is on the same page as you about whether these are GNUC
> > extensions, this conversation will go nowhere.
> >
> > You are of the opinion that "GCC currently behaves a certain way when
> > compiling the code" means that the behavior is documented and specified
> > as a "C Extension" for the GNUC language dialect.
>
> Yes, by the definition of ``extension'' used by everyone except you.
>

Wrong. I wouldn't bother replying to you again in this thread, but I feel
that as a gcc maintainer I should confirm that Eli S. is right here; and
nobody else I know agrees with your definition of extension as "every
non-standard aspect of the compiler's behaviour, whether intentional or
accidental". That's just silly.



> > You've provided some excuses like "C++ is a valid language for writing
> > documentation in, and the HTML docs are lacking", but your arguments are
> > not convincing.
> >
> > GCC has formal documentation. It is written in HTML. If it is lacking,
> > then the only valid move is to improve the HTML documentation and then
> > abide by it. In the absence of documentation, all behavior is, well,
> > "undocumented", which ***definitely*** means it isn't a formal GNUC
> > language dialect extension.
>
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.
>

Some is in docbook XML, and some is in HTML (namely the release notes).



> > You can stop arguing your opinions based on what running gcc or g++
> > produces in the form of machine code. What gcc or g++ produces in the
> > form of machine code is not guaranteed even across bugfix releases --
> > your only guarantee is that if it is documented in the ISO standards
> > documents or in the GCC html manual, the produced machine code shall be
> > in accordance with what the documentation says it shall do.
>
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?
>
> > Undefined and undocumented behavior is not a language extension. It is
> > undefined and undocumented behavior.
>
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.
>

No, Eli S. is quite right.


> > You may feel free to take an exact GCC release (source or binary),
> > analyze it, reverse-engineer it, or verify that it does what you want
> > it to do, and then trust that those undefined and undocumented
> > behaviors are ***benevolent***, but that doesn't cause it to be
> > defined and documented, and your trust will, if you are wise, depend
> > on you pinning an exact source code commit of the compiler. Do not
> > depend on bugfix releases of GCC to preserve your undocumented
> > semantics. They may or they may not, but if they don't, it's not a GCC
> > bug, because it is ***undocumented***.
>
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
>

And when the compiler is wrong and the documentation is correct, the
compiler is fixed.



> And it's not just GCC.  Almost all programs work this way.
>

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:38, Po Lu via Gcc wrote:

> No, all you have to do is to tell GNU CC to compile Standard C.  But
> what's being debated here is the behavior of GNU CC when translating
> both Standard C and GNU C, so your demonstration is almost completely
> pointless.
> 
You keep using the term "Standard C", but you are using it incorrectly.

"Standard C" means "The language C as recognised by standardisation 
bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18. 
(The standard was completed in C17, but not actually published until C18.)

If you want to refer to older standards (or unpublished future 
standards), you should do so explicitly - C90, C99, C11, C23.

Then there are "extended standards" - specific documented extensions on 
top of an official standard.  "gnu17" would be an example of that.

Any language from before the first ANSI C is /not/ standard, since it is 
not based on any standards document.  The nearest would be the de-facto 
"standard" (anything "de-facto" is, by definition, not an actual 
standard) language described in the first edition of "The C Programming 
Language", and known as "K&R C".  Many of the C compilers of that time 
followed the book and implemented - modulo bugs, extensions, 
inconsistencies, and missing features - the language "K&R C".  Many also 
had their own variants, as "C" was already popular before the book was 
published.


So - if you are referring to "K&R C", then use that term.  It is quite 
well defined, and accurately describes a popular pre-standard C language.

And you may note that if you look at the GCC manual, it supports all 
standards of C (at least as closely as possible).  All /standards/. 
"K&R C" is not a standard, and not officially supported by GCC - there 
has never, to my knowledge, been any kind of guarantee that GCC would 
support pre-standard syntax.  There has only been a guarantee that 
appropriate choices of flags would cause pre-standard syntax to be 
detected and rejected or diagnosed.  Ironically, the discussion here, 
with its suggestions of explicit flags to allow "K&R C" constructs, has 
come closer to guaranteeing support for that pre-standard dialect than 
GCC has ever had before.

<https://gcc.gnu.org/onlinedocs/gcc/Standards.html>
<https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html>




(When people refer to "ANSI C", they almost invariably mean the ANSI 
standard from 1989 that formed, after a bit of section renumbering, ISO 
C90, it is worth remembering that ANSI actually delegates the C 
standardisation to ISO.  So "ANSI C" refers to the same language as 
C17/C18.)

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Sun, 14 May 2023, 10:47 David Brown, <david.brown@hesbynett.no> wrote:

> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>
> > No, all you have to do is to tell GNU CC to compile Standard C.  But
> > what's being debated here is the behavior of GNU CC when translating
> > both Standard C and GNU C, so your demonstration is almost completely
> > pointless.
> >
> You keep using the term "Standard C", but you are using it incorrectly.
>
> "Standard C" means "The language C as recognised by standardisation
> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
> (The standard was completed in C17, but not actually published until C18.)
>
> If you want to refer to older standards (or unpublished future
> standards), you should do so explicitly - C90, C99, C11, C23.
>
> Then there are "extended standards" - specific documented extensions on
> top of an official standard.  "gnu17" would be an example of that.
>
> Any language from before the first ANSI C is /not/ standard, since it is
> not based on any standards document.  The nearest would be the de-facto
> "standard" (anything "de-facto" is, by definition, not an actual
> standard) language described in the first edition of "The C Programming
> Language", and known as "K&R C".  Many of the C compilers of that time
> followed the book and implemented - modulo bugs, extensions,
> inconsistencies, and missing features - the language "K&R C".  Many also
> had their own variants, as "C" was already popular before the book was
> published.
>
>
> So - if you are referring to "K&R C", then use that term.  It is quite
> well defined, and accurately describes a popular pre-standard C language.
>
> And you may note that if you look at the GCC manual, it supports all
> standards of C (at least as closely as possible).  All /standards/.
> "K&R C" is not a standard, and not officially supported by GCC - there
> has never, to my knowledge, been any kind of guarantee that GCC would
> support pre-standard syntax.



There used to be the -traditional option which was deprecated in gcc 3.1
and removed in gcc 3.3

https://gcc.gnu.org/gcc-3.1/changes.html
https://gcc.gnu.org/gcc-3.3/changes.html

There has only been a guarantee that
> appropriate choices of flags would cause pre-standard syntax to be
> detected and rejected or diagnosed.  Ironically, the discussion here,
> with its suggestions of explicit flags to allow "K&R C" constructs, has
> come closer to guaranteeing support for that pre-standard dialect than
> GCC has ever had before.
>
> <https://gcc.gnu.org/onlinedocs/gcc/Standards.html>
> <https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html>
>
>
>
>
> (When people refer to "ANSI C", they almost invariably mean the ANSI
> standard from 1989 that formed, after a bit of section renumbering, ISO
> C90, it is worth remembering that ANSI actually delegates the C
> standardisation to ISO.  So "ANSI C" refers to the same language as
> C17/C18.)
>
>
>

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

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

On Sun, 14 May 2023, 11:21 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> On Sun, 14 May 2023, 10:47 David Brown, <david.brown@hesbynett.no> wrote:
>
>> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>>
>> > No, all you have to do is to tell GNU CC to compile Standard C.  But
>> > what's being debated here is the behavior of GNU CC when translating
>> > both Standard C and GNU C, so your demonstration is almost completely
>> > pointless.
>> >
>> You keep using the term "Standard C", but you are using it incorrectly.
>>
>> "Standard C" means "The language C as recognised by standardisation
>> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
>> (The standard was completed in C17, but not actually published until C18.)
>>
>> If you want to refer to older standards (or unpublished future
>> standards), you should do so explicitly - C90, C99, C11, C23.
>>
>> Then there are "extended standards" - specific documented extensions on
>> top of an official standard.  "gnu17" would be an example of that.
>>
>> Any language from before the first ANSI C is /not/ standard, since it is
>> not based on any standards document.  The nearest would be the de-facto
>> "standard" (anything "de-facto" is, by definition, not an actual
>> standard) language described in the first edition of "The C Programming
>> Language", and known as "K&R C".  Many of the C compilers of that time
>> followed the book and implemented - modulo bugs, extensions,
>> inconsistencies, and missing features - the language "K&R C".  Many also
>> had their own variants, as "C" was already popular before the book was
>> published.
>>
>>
>> So - if you are referring to "K&R C", then use that term.  It is quite
>> well defined, and accurately describes a popular pre-standard C language.
>>
>> And you may note that if you look at the GCC manual, it supports all
>> standards of C (at least as closely as possible).  All /standards/.
>> "K&R C" is not a standard, and not officially supported by GCC - there
>> has never, to my knowledge, been any kind of guarantee that GCC would
>> support pre-standard syntax.
>
>
>
> There used to be the -traditional option which was deprecated in gcc 3.1
> and removed in gcc 3.3
>
> https://gcc.gnu.org/gcc-3.1/changes.html
> https://gcc.gnu.org/gcc-3.3/changes.html
>

But even as far back as gcc 2.95.3 that was documented only to "attempt" to
support "some" features of pre -standard C:

"Attempt to support some aspects of traditional C compilers."



>
> There has only been a guarantee that
>> appropriate choices of flags would cause pre-standard syntax to be
>> detected and rejected or diagnosed.  Ironically, the discussion here,
>> with its suggestions of explicit flags to allow "K&R C" constructs, has
>> come closer to guaranteeing support for that pre-standard dialect than
>> GCC has ever had before.
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Standards.html>
>> <https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html>
>>
>>
>>
>>
>> (When people refer to "ANSI C", they almost invariably mean the ANSI
>> standard from 1989 that formed, after a bit of section renumbering, ISO
>> C90, it is worth remembering that ANSI actually delegates the C
>> standardisation to ISO.  So "ANSI C" refers to the same language as
>> C17/C18.)
>>
>>
>>

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:28, Po Lu via Gcc wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
> 
>> Quoting my previous reply on the topic.
>>
>> Until everyone is on the same page as you about whether these are GNUC
>> extensions, this conversation will go nowhere.
>>
>> You are of the opinion that "GCC currently behaves a certain way when
>> compiling the code" means that the behavior is documented and specified
>> as a "C Extension" for the GNUC language dialect.
> 
> Yes, by the definition of ``extension'' used by everyone except you.

I can't speak for "everyone", and I don't think you can either.  But I 
believe I am safe in saying that everyone who has expressed an opinion 
in this thread, agrees with Eli's definition - GCC C extensions are what 
the GCC C manual documents as extensions.

The behaviour of a particular compiler does not define the extensions. 
At best, these are "undocumented features" - if you find them consistent 
enough and useful enough on a particular version of a particular 
compiler, then you may be willing to rely on them despite a lack of any 
kind of guarantees or documentation.

(You might note that there are several compilers, not just GCC, that 
implement many of the GNU C extensions.  I don't believe any of them 
makes any guarantees about your imagined undocumented extensions either.)

> 
>> Undefined and undocumented behavior is not a language extension. It is
>> undefined and undocumented behavior.
> 
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.

No, it becomes an artefact of the particular implementation.  And if you 
have studied that implementation closely enough to see that it fulfils 
the specifications you want, not just its actual specifications, then 
feel free to keep that implementation and use it.  But you have 
absolutely no basis for expecting that any other implementation (such as 
future gcc versions) implement the same undocumented specifications.

> 
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.
> 

It is a sad fact that many programs /are/ written that way - rushed 
coding under a manager's whip until the code works well enough to pass 
some basic tests, then it is shipped to end users.  Documentation, if 
any, is written afterwards with barely a nod towards a specification.

The /correct/ way to write code is to specify first (as formally and 
thoroughly as appropriate for the project), and have everyone agree that 
the specification fulfils the requirements for the program and that it 
is feasible to implement in practice.  /Then/ start writing code.  If 
the specification is user readable, then it forms the basis for the user 
documentation - if not, then user documentation can be written before, 
during or after code development.

For a living and evolving project like GCC, this all works in lots of 
small steps and in practice changes to the code and changes to the 
documented specifications get committed together, to keep them 
synchronised.  But it is always logically a documented feature and code 
that implements that specification.  (The specification can be a bug 
report, not just the user documentation.)


Attempting to do what you describe - look at the behaviour of gcc in 
practice, document it and call it the specification - would be insane. 
I've already tried to explain on this thread how the logical consequence 
of such ideas is total stagnation of the gcc development.  Look at the 
bugzilla database for GCC - it is /huge/.  Every (valid) bug there is a 
case where GCC does not do what it was supposed to do - what it is 
/documented/ to do.  You would have the GCC folks spend their time 
updating the documentation to redefine these bugs as previously 
undocumented features, rather than fixing the bugs in the code, and 
requiring all future versions of gcc to maintain bug-for-bug 
compatibility with the older versions.

Or could it be that you think this only applies to the features that 
/you/, personally, want to keep?  Sod the rest of the world, as long as 
/you/ don't need to fix your code?


I've come across a fair number of C programmers with your attitude 
before.  Generally they don't realise the consequences of their desires, 
or how limiting they are.  They think they are fighting on behave of 
others in the same position, arguing that they should be able to 
continue to rely on undocumented and unwarranted behaviour that has 
worked before.  It sounds reasonable, until you look at what it actually 
implies - and until you consider all the other groups who also want to 
rely on /different/ selections of undocumented and unwarranted 
behaviour.  And then, of course, there are all those C programmers who 
try hard to stick to actual documented and warranted behaviour, and 
would like the best warnings and development aids to help them write 
good, correct code, and who then want the results to run as efficiently 
as possible.

The irony is that the people who want their compiler to behave as it 
always has (for their particular type of code, and their particular 
unwritten ideas of how to behave) usually complain loudest about GCC. 
And GCC is, of all the compilers I have used, the best at having 
/documented/ flags to give these people exactly what they are looking 
for.  For some, it is "-fwrapv", others 
"-fno-delete-null-pointer-checks", and others it is 
"-Wno-implicit-function-declaration".

David

Re: More C type errors by default for GCC 14

[Po Lu]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Does this mean you've conceded the point, and no longer think it is
> written in C++?

No.

> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't been generally reiterated, or even iterated.

Parse error.

> Repeating this statement won't make it true.

Before you say this, I suggest that you take some time to look at
yourself in a mirror.

> In fact, lots and lots and lots of programs do indeed operate such that
> the documentation specifies how the program shall behave, and when the
> program fails to behave in the manner in which it is documented to
> behave, the program shall be fixed.
>
> We call these failures to behave according to the documentation,
>
>
> Bugs.
>
>
> Occasionally it is also called specification-driven development.
>
> ...
>
> In cases where the documentation says nothing at all, for good or ill,
> the behavior of the program is undefined -- users cannot rely on it, for
> they cannot know what is intended and what is not intended -- in this
> case, the intended behavior must be defined, documented, and
> implemented, and "the program currently does X" gets one vote out of
> many and is not guaranteed to get its way.
>
> Very often in such cases the best user-serving thing to do is to define
> the behavior as "shall not be used, and for legacy reasons if you use it
> it will continue to do X but raise a warning telling you that you are
> required to stop depending on it" and possibly even "it may disappear in
> semver version YYY".

Where is it written that GNU CC follows your so-called
``specification-driven development''?

Here is an explanation from one of the original GCC developers.  It
discusses strict aliasing, but the same principles apply here:

(199909100634.CAA01815@psilocin.gnu.org)

      My comment is similar to Mark's comment.  Documentation, what can
      we document as working?

  We should not even try to document that these cases work.
  Documentation is what we do when we add a feature.

  I am not proposing this as a feature, just as a way to avoid evitable
  trouble for users.  We should not even try to document a class of
  cases that are "supposed" to work, because I'm not saying these are
  "supposed" to work.  We should just let them work.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

      Anway, more questions from me than answers...  Off hand though, if
      we can make the compiler generate `right' code in more cases, even
      if the users code is wrong, I think we should probably do it.

  In C, we cannot divide all user code into "right" and "wrong" in this
  kind of simple way, and certainly not based on the ISO standard.  That
  standard is just the decisions of a certain committee (which I was a
  member of) about what cases conforming compilers should commit to
  support.  We must not let ourselves start thinking that C code is
  "wrong", just because it is not conforming ISO C code.

  C programs use many cases that are not conforming, but do work.  This
  will be true for as long as C is used, because changing it would
  require major changes in the C language.

  From time to time, there is a real *need* to make some of these cases
  stop working, for the sake of some benefit that users want.  When this
  happens, we should do it; the user community will accept it, because
  they will see that it is being done for their sake.  Some will
  grumble, but the users who appreciate the benefits will convince them.

  But when there is no *need* to break these cases, when we can keep
  them working fairly easily, we should keep them working.  If we break
  them unnecessarily, we invite the legitimate anger of the users.

and another (199909100634.CAA01812@psilocin.gnu.org):

      However, I have a rather serious objection: it means that users
      cannot tell whether their code is valid, even according to the GCC
      rules, without knowing the internals of the compiler.

  This has always been true.  It is true in the current version of GCC
  with regard to aliasing, even when -fstrict-aliasing is used.  It is
  part of the nature of C.

  The goal of trying to avoid it is unrealistic and misguided; it can't
  be done.  So this cannot be a valid reason to reject a change.

      The compiler should continue to aggressively break code that
      misbehaves in this way.

  This proposes to break users' code, just to bully them into changing
  it.  That is a callous and harsh attitude towards the users of GCC.
  No wonder users are angry.  They know that the problems are not due to
  necessity, but due to callous disregard for them.

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always say no reluctantly--never eagerly.  We
  should never aggressively cause trouble for users today, just because
  someday it might be necessary.  That is like amputating limbs because
  someday they might be crushed.

  This treatment of users brings shame on the GNU Project.  I ask
  everyone therefore not to suggest that we should treat users this way.

> Sound familiar? A bit like GCC triggering a warning, telling you that
> what you're doing is bad and should not be relied on?

A diagnostic message is supposed to inform me of a diagnosis by the
translator.  The severity of the diagnosis, is, as always, up to the
user to decide, as long as enough information remains for translation to
continue.

> But GCC isn't dropping support for it in semver version anything, just
> guarding its use behind an opt-in flag.

Which is liable to disappear in the future, as many have before it.

Re: More C type errors by default for GCC 14

[Po Lu]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> Wrong. I wouldn't bother replying to you again in this thread, but I
> feel that as a gcc maintainer I should confirm that Eli S. is right
> here; and nobody else I know agrees with your definition of extension
> as "every non-standard aspect of the compiler's behaviour, whether
> intentional or accidental". That's just silly.

GCC's support for implicit int is clearly intentional.
I never claimed that accidental GNU CC behavior was part of GNU C.

> No, Eli S. is quite right.

[...]

> And when the compiler is wrong and the documentation is correct, the
> compiler is fixed.

And the documentation is wrong, while the translator is correct.

GCC development, being part of the GNU project, is supposed to act in
its interests and that of Free Software in general.  I remind you of of
this statement, which was made here, on this list, by clearer minds:

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always say no reluctantly--never eagerly.  We
  should never aggressively cause trouble for users today, just because
  someday it might be necessary.  That is like amputating limbs because
  someday they might be crushed.

  This treatment of users brings shame on the GNU Project.  I ask
  everyone therefore not to suggest that we should treat users this way.

And yes, such shameful treatment is directly harmful to the goals of the
GNU Project: at least one organization, likely more, has been forced to
adopt proprietary compilers as a direct result.

Re: More C type errors by default for GCC 14

[Arsen Arsenović]

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


Po Lu via Gcc <gcc@gcc.gnu.org> writes:

...

> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?

Any development style making documentation a source of truth matches
this principle.  This does not refer to ISO specifications specifically,
though, normally, unless the standard disagrees with reality, as
implicit-... did many years ago, ISO decisions are taken seriously.

> Here is an explanation from one of the original GCC developers.  It
> discusses strict aliasing, but the same principles apply here:
>
> (199909100634.CAA01815@psilocin.gnu.org)
>
>       My comment is similar to Mark's comment.  Documentation, what can
>       we document as working?
>
>   We should not even try to document that these cases work.
>   Documentation is what we do when we add a feature.
>
>   I am not proposing this as a feature, just as a way to avoid evitable
>   trouble for users.  We should not even try to document a class of
>   cases that are "supposed" to work, because I'm not saying these are
>   "supposed" to work.  We should just let them work.
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>       Anway, more questions from me than answers...  Off hand though, if
>       we can make the compiler generate `right' code in more cases, even
>       if the users code is wrong, I think we should probably do it.
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.
>
> and another (199909100634.CAA01812@psilocin.gnu.org):
>
>       However, I have a rather serious objection: it means that users
>       cannot tell whether their code is valid, even according to the GCC
>       rules, without knowing the internals of the compiler.
>
>   This has always been true.  It is true in the current version of GCC
>   with regard to aliasing, even when -fstrict-aliasing is used.  It is
>   part of the nature of C.
>
>   The goal of trying to avoid it is unrealistic and misguided; it can't
>   be done.  So this cannot be a valid reason to reject a change.
>
>       The compiler should continue to aggressively break code that
>       misbehaves in this way.
>
>   This proposes to break users' code, just to bully them into changing
>   it.  That is a callous and harsh attitude towards the users of GCC.
>   No wonder users are angry.  They know that the problems are not due to
>   necessity, but due to callous disregard for them.
>
>   We cannot do everything all users want, and sometimes a maintainer has
>   to say no to users.  "You cannot please everyone," as the saying goes.
>   There are many kinds of reasons which can sometimes be good reasons to
>   say no.
>
>   But maintainers should always say no reluctantly--never eagerly.  We
>   should never aggressively cause trouble for users today, just because
>   someday it might be necessary.  That is like amputating limbs because
>   someday they might be crushed.
>
>   This treatment of users brings shame on the GNU Project.  I ask
>   everyone therefore not to suggest that we should treat users this way.
>
>> Sound familiar? A bit like GCC triggering a warning, telling you that
>> what you're doing is bad and should not be relied on?
>
> A diagnostic message is supposed to inform me of a diagnosis by the
> translator.  The severity of the diagnosis, is, as always, up to the
> user to decide, as long as enough information remains for translation to
> continue.

It is, after this proposal is accepted, still up to the user to decide.
The only difference is that the default would be friendlier to new code
and users and most code that exists today, rather than to very old code
and incorrect code.

Additionally, there isn't enough information to compile.  The compiler
makes up new information to fill in the gaps.

If that definition accepted, most error recovery should be turned into
valid code paths that participate as GNU extensions, for instance,
there's no reason that:

   int f (int x) { x += 10 return x + 123 }

shouldn't compile, as the compiler knows where to insert semicolons to
make it (probably) work.  I'd say that extension is more acceptable than
the ones being proposed into turning into errors by default, since it
isn't very ambiguous, unlike an implicit function declaration or such.

>> But GCC isn't dropping support for it in semver version anything, just
>> guarding its use behind an opt-in flag.
>
> Which is liable to disappear in the future, as many have before it.

It has been 25 years since the addition of -fpermissive to G++.  I'm
optimistic.

Have a lovely day.
-- 
Arsen Arsenović

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

Re: More C type errors by default for GCC 14

[Mark Wielaard]

Hi Po,

On Fri, May 12, 2023 at 09:53:30PM +0800, Po Lu via Gcc wrote:
> I don't want anything, seeing as I've been using GCC less and less over
> the years (for this and other reasons.)  I'm just throwing in my two or
> so cents.

I think you have contributed more than two cents and it time to stop
repeating your opinion over and over again (and for others to stop
replying to your posts). You have posted more than anybody else to
this thread and it is not contributing anything new. Please let the
actual gcc maintainers work out the technical details of the default
diagnostics.

Thanks,

Mark

Re: More C type errors by default for GCC 14

[Nicholas Vinson]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>> Wrong. I wouldn't bother replying to you again in this thread, but I
>> feel that as a gcc maintainer I should confirm that Eli S. is right
>> here; and nobody else I know agrees with your definition of extension
>> as "every non-standard aspect of the compiler's behaviour, whether
>> intentional or accidental". That's just silly.
> GCC's support for implicit int is clearly intentional.
> I never claimed that accidental GNU CC behavior was part of GNU C.

You might not have explicitly stated that, but you have made that 
argument in this thread.

You have asserted that the compiler's behavior, and not its 
documentation, determines what should be consider a language extension.

That assertion when taken to its natural conclusion show support for the 
idea that "accidental GNU CC behavior" should be considered a language 
extension, and by becoming a language extension it would be part of GNU C.

If the behavior, and not the documentation, determines what is and is 
not an extension unless it's "accidental behavior", then how is anyone 
to know what is or is not a GNU C extension?

Re: More C type errors by default for GCC 14

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Any development style making documentation a source of truth matches
> this principle.  This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken seriously.

We're not talking about the C Standard here.  Eli S. is claiming that
gcc.info is the source of truth for the behavior of GCC, and whenever
some behavior of GCC is not documented (or contradicts the
documentation), GCC should be fixed to behave as its documentation
specifies.

> It is, after this proposal is accepted, still up to the user to decide.
> The only difference is that the default would be friendlier to new code
> and users and most code that exists today, rather than to very old code
> and incorrect code.

That's not correct.  It would be as friendly to new code as it is now --
but old (and very likely still correct) code would be put at a
disadvantage.

> Additionally, there isn't enough information to compile.  The compiler
> makes up new information to fill in the gaps.

According to a specific formula that all C programmers (at least, those
who write such code) know.

> If that definition accepted, most error recovery should be turned into
> valid code paths that participate as GNU extensions, for instance,
> there's no reason that:
>
>    int f (int x) { x += 10 return x + 123 }
>
> shouldn't compile, as the compiler knows where to insert semicolons to
> make it (probably) work.  I'd say that extension is more acceptable than
> the ones being proposed into turning into errors by default, since it
> isn't very ambiguous, unlike an implicit function declaration or such.

Unfortunately, this has never worked in any C compiler, and is very
ambiguous.  Implicit int and function declarations have been included in
every ANSI and K&R C compiler, and then some more after that, so what
the compiler should do is very precisely specified and known.

> It has been 25 years since the addition of -fpermissive to G++.  I'm
> optimistic.

But -fpermissive is considered ``useful'' by the many loud people who
find it necessary to compile C as C++.

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists)]

On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
>>   jwakely.gcc@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.

Re: More C type errors by default for GCC 14

[Michael Matz]

Hello,

On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:

> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > > One fairly big GCC-internal task is to clear up the C test suite so that
> > > it passes with the new compiler defaults.  I already have an offer of
> > > help for that, so I think we can complete this work in a reasonable time
> > > frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Yes, this!  Try to (!) never change committed testcase souces, however 
invalid they may be (changing how they are compiled, including by 
introducing new dg-directives and using them in comments, is of course 
okay).

(And FWIW: I'm fine with Florians proposal.  I personally think the 
arguments for upgrading the warnings to errors are _not_ strong enough, 
but I don't think so very strongly :) )


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Michael Matz]

Hello,

On Fri, 12 May 2023, Florian Weimer wrote:

> * Alexander Monakov:
> 
> > This is not valid (constraint violation):
> >
> >   unsigned x;
> >
> >   int *p = &x;
> >
> > In GCC this is diagnosed under -Wpointer-sign:
> >
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
> 
> Thanks for the reference.  I filed:
> 
>   -Wpointer-sign must be enabled by default
>   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836>

Can you please not extend the scope of your proposals in this thread but 
create a new one?

(FWIW: no, this should not be an error, a warning is fine, and I actually 
think the current state of it not being in Wall is the right thing as 
well)


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists)]

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote:
> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
>>> One fairly big GCC-internal task is to clear up the C test suite so that
>>> it passes with the new compiler defaults.  I already have an offer of
>>> help for that, so I think we can complete this work in a reasonable time
>>> frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Whilst there is historical precedent for -fpermissive, I have to say 
that I don't like it.  The problem is that it is too imprecise as to 
what it means (and changes over time).  It also becomes the lazy way to 
paper over the problems being exposed and, in future, may mean that 
other (perhaps more important) issues that are detectable will be 
silently ignored if it becomes widely used.

R.

Re: More C type errors by default for GCC 14

[Eric Gallager]

On 5/15/23, Richard Earnshaw (lists) via Gcc <gcc@gcc.gnu.org> wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović <arsen@aarsen.me>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
>>>   jwakely.gcc@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.
>

I support this plan for using -Werror= and having it be split based on
whether -std= is set to a strict ANSI option or a GNU option; is there
a way to do that in the optfiles, or would it have to be handled at
the specs level instead?

> At some point that std setting will become the default and the overall
> goal is achieved.
>
> R.
>

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Eric Gallager via Gcc:

> I support this plan for using -Werror= and having it be split based on
> whether -std= is set to a strict ANSI option or a GNU option; is there
> a way to do that in the optfiles, or would it have to be handled at
> the specs level instead?

This isn't going to work well because -std=c17 (for example) disables
_DEFAULT_SOURCE for glibc, so lots of declarations go missing from the
glibc header files.  I don't see why these things should be tied
together because as I see it, this is not about standards conformance
(warnings make GCC conforming already), but programmer convenience.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Michael Matz:

> Hello,
>
> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> * Alexander Monakov:
>> 
>> > This is not valid (constraint violation):
>> >
>> >   unsigned x;
>> >
>> >   int *p = &x;
>> >
>> > In GCC this is diagnosed under -Wpointer-sign:
>> >
>> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
>> 
>> Thanks for the reference.  I filed:
>> 
>>   -Wpointer-sign must be enabled by default
>>   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836>
>
> Can you please not extend the scope of your proposals in this thread but 
> create a new one?

I understood Joseph as asking for exploring a broadened scope, so I
looked into that.

> (FWIW: no, this should not be an error, a warning is fine, and I actually 
> think the current state of it not being in Wall is the right thing as 
> well)

I don't understand why we do not warn by default and warn with -Wall.  I
would expect this to be either a documented extension (no warning with
-Wall), or a warning by default (because it's a conformance issue).  Is
there any conformance issue that is treated in the same way?

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Alexander Monakov]

On Tue, 16 May 2023, Florian Weimer wrote:

> > (FWIW: no, this should not be an error, a warning is fine, and I actually 
> > think the current state of it not being in Wall is the right thing as 
> > well)

(this is mixed up, -Wpointer-sign is in fact enabled by -Wall)

> I don't understand why we do not warn by default and warn with -Wall.  I
> would expect this to be either a documented extension (no warning with
> -Wall), or a warning by default (because it's a conformance issue).  Is
> there any conformance issue that is treated in the same way?

Another one is -Wpointer-arith (pointer arithmetic on 'void *').

Alexander

Re: More C type errors by default for GCC 14

[Jakub Jelinek]

On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> 
> On Tue, 16 May 2023, Florian Weimer wrote:
> 
> > > (FWIW: no, this should not be an error, a warning is fine, and I actually 
> > > think the current state of it not being in Wall is the right thing as 
> > > well)
> 
> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> 
> > I don't understand why we do not warn by default and warn with -Wall.  I
> > would expect this to be either a documented extension (no warning with
> > -Wall), or a warning by default (because it's a conformance issue).  Is
> > there any conformance issue that is treated in the same way?
> 
> Another one is -Wpointer-arith (pointer arithmetic on 'void *').

That is a documented GNU extension, so we shouldn't increase severity of
the diagnostics from the current state.

	Jakub

Re: More C type errors by default for GCC 14

[Jonathan Wakely]

On Tue, 16 May 2023 at 12:01, Jakub Jelinek wrote:
>
> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 16 May 2023, Florian Weimer wrote:
> >
> > > > (FWIW: no, this should not be an error, a warning is fine, and I actually
> > > > think the current state of it not being in Wall is the right thing as
> > > > well)
> >
> > (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> >
> > > I don't understand why we do not warn by default and warn with -Wall.  I
> > > would expect this to be either a documented extension (no warning with
> > > -Wall), or a warning by default (because it's a conformance issue).  Is
> > > there any conformance issue that is treated in the same way?
> >
> > Another one is -Wpointer-arith (pointer arithmetic on 'void *').
>
> That is a documented GNU extension, so we shouldn't increase severity of
> the diagnostics from the current state.

I was about to say that this one really is a documented extension.
It's caused a few bugs in libstdc++ over the years though. Arithmetic
on void* makes sense, but pointer arithmetic on function pointers is
just weird.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Jakub Jelinek:

> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>> 
>> On Tue, 16 May 2023, Florian Weimer wrote:
>> 
>> > > (FWIW: no, this should not be an error, a warning is fine, and I actually 
>> > > think the current state of it not being in Wall is the right thing as 
>> > > well)
>> 
>> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
>> 
>> > I don't understand why we do not warn by default and warn with -Wall.  I
>> > would expect this to be either a documented extension (no warning with
>> > -Wall), or a warning by default (because it's a conformance issue).  Is
>> > there any conformance issue that is treated in the same way?
>> 
>> Another one is -Wpointer-arith (pointer arithmetic on 'void *').
>
> That is a documented GNU extension, so we shouldn't increase severity of
> the diagnostics from the current state.

Right, it's also widely used, and harmless for void *.  For function
pointers, it's much more dubious, and not meaningful at all for some
targets.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Jason Merrill]

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

On Tue, May 16, 2023 at 3:06 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
wrote:

> * Eric Gallager via Gcc:
>
> > I support this plan for using -Werror= and having it be split based on
> > whether -std= is set to a strict ANSI option or a GNU option; is there
> > a way to do that in the optfiles, or would it have to be handled at
> > the specs level instead?
>
> This isn't going to work well because -std=c17 (for example) disables
> _DEFAULT_SOURCE for glibc, so lots of declarations go missing from the
> glibc header files.  I don't see why these things should be tied
> together because as I see it, this is not about standards conformance
> (warnings make GCC conforming already), but programmer convenience.
>

Agreed, -std=c?? is supposed to disable only the extensions that conflict
with accepting all conforming code.  Diagnosing non-conforming code is the
job of -pedantic(-errors).

Can you explain again why upgrading -Wint-conversion (instead of
-Wimplicit) isn't the right solution for catching these bugs?  You
mentioned that this would need more changes to Fedora packages, but
wouldn't those cases also be fixing real bugs, unlike the changes needed to
avoid -Wimplicit in autoconf?

Jason

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Jason Merrill:

> As a compromise, it should be possible to error by default only in
> cases where the implicit int (including as a return value) is either
> the source or target of a non-value-preserving conversion, as those
> are very likely to be bugs.  That seems desirable for both camps.

Not sure, malloc returning 31-bit pointers goes a long way towards
maintaining int/pointer compatibility for 64-bit systems, too.  People
might actually have a working implicit-declared malloc on 64-bit today,
and still argue against the changes.

> A simpler change to catch this particular bug would be to make
> -Wint-conversion an error by default iff the sizes differ.

That doesn't address other bugs around implicitly-declared functions,
such as the bool/int ABI incompatibility, or the lack of type checking
for arguments.  I don't see those programmer mistakes because I think
it's easier to debug them on your own: swapped arguments are visible in
the source code, and GDB probably gives you enough data as well.  So I
suspect that people figure this out on their own.  They are still
wasting time on this, but probably somewhat less.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 15:10, Basile Starynkevitch wrote:
> Hello all,
> 
> After a suggestion by Eric Gallager
>> Idea for a compromise: What if, instead of flipping the switch on all
>> 3 of these at once, we staggered them so that each one becomes a
>> default in a separate release? i.e., something like:
>>
>> - GCC 14: -Werror=implicit-function-declaration gets added to the 
>> defaults
>> - GCC 15: -Werror=implicit-int gets added to the defaults
>> - GCC 16: -Werror=int-conversion gets added to the defaults
>>
>> That would give people more time to catch up on a particular warning,
>> rather than overwhelming them with a whole bunch all at once. Just an
>> idea.
> 
> Eli Zaretskii <eliz@gnu.org> wrote on 10 may 2023, at 14:00
> 
>> And that is just one example of perfectly valid reasons for not
>> wanting or not being able to make changes to pacify GCC.
>>
>> Once again, my bother is not about "villains" who don't want to get
>> their act together, my bother is about cases such as the one above,
>> where the developers simply have no practical choice.
>>
>> And please don't tell me they should use an older GCC, because as
>> systems go forward and are upgraded, older GCC will not work anymore.
> 
> 
> My experience is that for safety critical software (per DOI 178C, 
> embedded in aircrafts, or for the French covid breathing machine on 
> https://github.com/Recovid/Controller ) the regulations, funders, and 
> authorities requires a very specific version of GCC with very specific 
> compilation flags.
> 
> 
> Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the 
> compilation flags (even changing -O1 by -O2) requires written (on paper) 
> approval by a large number of human persons, and formal certifications 
> (eg ISO9001, ISO27001 procedures) and lots of checks and headaches.
> 
> 
> I do know several persons making their living of these constraints.
> 
> I do know several corporations making a living from them (and keeping 
> decade older GCC compiler binaries on many disks).
> 
> So I really think that for safety critical software (whose failure may 
> impact lives) people are using an older (and well specified) GCC.
> 
> 
> Of course, to compile an ordinary business web service (e-shop for 
> clothes) with e.g. libonion (from https://github.com/davidmoreno/onion 
> ...) or to compile a zsh.org from source code (for or on a developer's 
> laptop) the constraints are a lot lighter.
> 
> Regards!
> 

In my line of work (small-systems embedded programming), the source for 
a program does not just include the C source code.  It includes the 
build system, compiler version, the flags used, and the library used - 
everything that can affect the resulting binary.  I realise I am far 
more paranoid about that kind of thing than the majority of developers, 
but it is also noteworthy that there is a trend towards reproducible 
builds in more mainstream development.

The oldest gcc I have on my machine is 2.95.3 for the 68k, from 1998.  I 
have some older compilers, but they are not gcc.

I wouldn't say I made a living out of this, but I have had a customer 
who was very happy that I could make a fix in a program I wrote 20 years 
previously, and could compile it with exactly the same tools as I used then.

One of the reasons I use gcc (in a world where companies are willing to 
pay $5000 for tools from the likes of Green Hills) is that I can keep 
the old versions around, and copy and use them at will.

And for those that are more demanding than me, they can of course 
archive the sources for gcc (and other parts of the toolchain).

Those that /really/ need old versions of the toolchain, can use old 
versions of the toolchain.  And if gcc 14 changes in such a way that 
distro maintainers can't use it to build ancient packages, then they 
should make gcc-13 a part of their base packages as well as current gcc, 
and ship gcc version 13 for as long as they ship "ed", "rn" and other 
software from the middle ages.

Re: More C type errors by default for GCC 14

[Eli Zaretskii]

> From: Marcin Jaczewski <marcinjaczewski86@gmail.com>
> Date: Wed, 10 May 2023 14:41:40 +0200
> 
> Did you even check if the compiler outpost is still correct?

Yes.

> You mention "validations and verifications", do you do the same
> with the new compiler?

Yes.  But that is a fraction of the effort needed when the source
changes.

> If you can't touch code then you SHOULD not upgrade the compiler.

As I tried to explain, this is not really possible, unless the entire
system is also kept without any changes, which is also impossible,
because hardware gets old and needs to be replaced, and newer hardware
doesn't support old systems.

> Any big project (like Linux) shows these two rules are critical,
> there were multiple cases of security bugs caused by subtle change
> in behavior of the compiler.
> Compiling very old code is lability if nobody knows how it should work and
> nobody maintains it. Who can give you guarantee that the result is correct?
> Very old programs should even by default reject new compilers by default until
> someone does not check if it correctly compiles on new compilers.

This is all true, but the same problems exist even if the programs
don't use outdated C dialect.  So these issues are independent, almost
orthogonal to the issue at hand.

Re: More C type errors by default for GCC 14

[Basile Starynkevitch]

Hello all,

After a suggestion by Eric Gallager
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
>
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
>
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

Eli Zaretskii <eliz@gnu.org> wrote on 10 may 2023, at 14:00

> And that is just one example of perfectly valid reasons for not
> wanting or not being able to make changes to pacify GCC.
>
> Once again, my bother is not about "villains" who don't want to get
> their act together, my bother is about cases such as the one above,
> where the developers simply have no practical choice.
>
> And please don't tell me they should use an older GCC, because as
> systems go forward and are upgraded, older GCC will not work anymore.


My experience is that for safety critical software (per DOI 178C, 
embedded in aircrafts, or for the French covid breathing machine on 
https://github.com/Recovid/Controller ) the regulations, funders, and 
authorities requires a very specific version of GCC with very specific 
compilation flags.


Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the 
compilation flags (even changing -O1 by -O2) requires written (on paper) 
approval by a large number of human persons, and formal certifications 
(eg ISO9001, ISO27001 procedures) and lots of checks and headaches.


I do know several persons making their living of these constraints.

I do know several corporations making a living from them (and keeping 
decade older GCC compiler binaries on many disks).

So I really think that for safety critical software (whose failure may 
impact lives) people are using an older (and well specified) GCC.


Of course, to compile an ordinary business web service (e-shop for 
clothes) with e.g. libonion (from https://github.com/davidmoreno/onion 
...) or to compile a zsh.org from source code (for or on a developer's 
laptop) the constraints are a lot lighter.

Regards!


PS : my pet open source project is the RefPerSys open source inference 
engine on http://refpersys.org/ and 
https://github.com/RefPerSys/RefPerSys ; it is explicitly thought for 
non-critical use (desktop, teaching, ...).

-- 
Basile Starynkevitch                  <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

More C type errors by default for GCC 14

[Marcin Jaczewski]

I think the biggest problem you have is that you try to upgrade the compiler
to compile code that nobody has touched in 30years.

Adding `-fpermissive` is the least concern you should have.

Did you even check if the compiler outpost is still correct?
As you are really on some obsolete functionality it could easily rot
and the new compiler can not handle it correctly.

You mention "validations and verifications", do you do the same
with the new compiler?

If you can't touch code then you SHOULD not upgrade the compiler.
If you upgrade the compiler you SHOULD upgrade code.

Any big project (like Linux) shows these two rules are critical,
there were multiple cases of security bugs caused by subtle change
in behavior of the compiler.
Compiling very old code is lability if nobody knows how it should work and
nobody maintains it. Who can give you guarantee that the result is correct?
Very old programs should even by default reject new compilers by default until
someone does not check if it correctly compiles on new compilers.