Re: More C type errors by default for GCC 14

[Florian Weimer <fweimer@redhat.com>]

* 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