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.