Re: More C type errors by default for GCC 14

["Arsen Arsenović" <arsen@aarsen.me>]

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