Re: Fixing configure failures from newer gcc

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Mon, 20 Oct 2025 at 03:49, Greg A. Woods <woods%planix.ca@localhost> wrote:
>
> At Mon, 20 Oct 2025 14:46:55 +1100, matthew green <mrg%eterna23.net@localhost> wrote:
> Subject: re: Fixing configure failures from newer gcc
> >
> > you still don't understand what i'm saying.
> >
> > code that has been building with -std=c99 or newer has never
> > *failed to compile* until gcc 14, and a lot of that code does
> > rely upon newer C standards.  you can either *fix the code*
> > or turn the errors back to warnings or nothing...
>
> Sorry but I don't think you said anything so far about code with mixed
> standards levels requirements, and your example didn't show that.  Is
> that mixed stuff all in one file, or different source files?

Are we picking nits?

A project's coding standard may specify:
- a base language, c90 say so prototypes should be used
- the features allowed from newer standards
It's that second line that sets the minimum compiler requirements, not
the first.  For instance, a project may specify that out-of-order
variable declarations are allowed; pushing the minimum to c99.  The
same goes for features like  <stdbool.h>, __VA_LIST__, ...  They each
push the minimum compiler and language requirements.

> Ideally code that is clearly only C90-compliant in places shouldn't rely
> on any newer constructs or features from a more recent language standard
> at the same time.
>
> However if it does make use of mixed standards then that's what
> "-fpermissive" is meant for, just as the documentation says.  (I note
> through testing that gcc-15 still seems to support "-fpermissive" even
> though the "Porting to GCC-15" guide doesn't mention it.)

That's not how I read -fpermissive's description.  The (GCC 15.2)
documentation, which is vague, lists (C):

-Wdeclaration-missing-parameter-type -Wimplicit-function-declaration
-Wimplicit-int -Wincompatible-pointer-types -Wint-conversion
-Wreturn-mismatch
The -fpermissive option is the default for historic C language modes
(-std=c89, -std=gnu89, -std=c90, -std=gnu90).

All of which look like the issues someone migrating to c90 might have
encountered in the '90s.  Not 2025.

If anything, mrg's example fits that mold. The c90 migration should
have found and fixed the issue yet, for some reason, the compiler just
waved the broken code through.  The new round of compilers finally got
around to closing that loophole.