At Mon, 20 Oct 2025 10:58:11 -0400, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
Subject: Re: Fixing configure failures from newer gcc
>
> 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?
I don't think so (but see below -- I'm trying to ascertain what the real
problem is with using "-std=gnu89" when it is "necessary").
> 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.
I would argue that is the old way. It's also not really the problem.
C23 introduces a new language that is disguised as a newer level above
C17 -- or at least that's how it is being presented by newer compilers
that are now allowed to throw errors for more egregious throwbacks to
K&R syntax ("required diagnostics" that are errors by default).
So, regardless of what a project's coding standard may say we end up
with code that still doesn't have prototypes, or which still relies on
default declarations like "int" returns, etc.
When such a project is then thrust upon a platform using a compiler that
"helpfully" defaults to "gnu23", well it obviously won't compile.
If you CANNOT fix that code then you either have to tell the compiler to
back off and compile as if it is 1989, or toss the project. Pkgsrc
can't fix the code by itself, but it can be configured tell the compiler
to back off (even if that has to be done manually on a per-package
basis, and it's not that hard for even an unskilled developer to figure
out and do).
But if the code also uses newer constructs or requires newer features,
and it wasn't written to carefully hide them behind the appropriate
__STDC_VERSION__ checks, then maybe it's not going to compile with
"-std=gnu89" either. (I think that's what mrg is implying, but his
example doesn't demonstrate that, so that's why I'm picking nits.)
In that case one either relies on something like GCC-14's "-fpermissive"
(which pkgsrc can also be taught to supply), or one tosses the project
in the dustbin. Or one changes one's mind and fixes the code. Pkgsrc,
as a build infrastructure, currently really only has the first two
options. (Until we make it "agentic" and give it the keys so it can
patch packages itself -- just kidding!)
Note too that things are also a bit different outside the warm cozy
confines of GCC and NetBSD's slow and careful almost years-behind rate
at adopting new versions of GCC.
The Clang world, at least on macos, has had a different take, and for
longer. Those of us developing on macos have dealt with these issues
for several years now already.
Perhaps Clang's blanket "-Wno-everything" approach is indeed best for
build systems like pkgsrc -- that way the old way of figuring out the
"minimum compiler requirements" still works and one usually doesn't have
to patch around old warts. But of course GCC doesn't know
"-Wno-everything" and instead relies on one knowing all the command-line
names of all the errors that need to be disabled and/or converted back
to warnings and so it's a game of whack-a-mole for each compiler variant.
So despite GCC and Clang appearing largely similar on the command line,
they do behave differently.
> > 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.
note by "rely on" I meant "use them without protecting them behind
appropriate __STDC_VERSION__ checks"
> > 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).
OK, so that does seem on the surface to be a bit different than what the
GCC-14 "Porting To" document says (or suggests), but I think the
difference is just in the point of view, not in anything technically
relevant. I see that the actual GCC-14 manual says the very same thing
as GCC-15.
I think the original "Porting To" language is more applicable to the end
user's perspective, while the manual's language seems to be more from
the compiler maintainer's perspective.
With "-std=c90" the compiler won't, or shouldn't, accept any newer
constructs or provide any newer features, and it will only issue
warnings instead of tripping errors for some critical old warts allowed
by C89/C90 (i.e. no errors for any new "required diagnostics").
Technically that seems to be implemented by turning "-fpermissive" on by
default along with C89, etc. so as to handle a downgrading of a number
of other warnings as well.
Meanwhile "-fpermissive" can still be mixed with "-std=gnu17" and will
still achieve the same result of compiling old warts without errors
while also supporting the newer language features. Thus the "Porting To
GCC-14" language.
Testing confirms this is true, at least for GCC-14 and GCC-15.
Technically Clang is similar, but you can only get there by turning off
all the warnings and errors entirely, and on macos at least you have to
do that even if you also use "-std=c89". (Well you can also play
whack-a-mole with turning off/converting individual errors.)
> All of which look like the issues someone migrating to c90 might have
> encountered in the '90s. Not 2025.
Indeed -- but in some cases apparently people were lazy and didn't
actually finish their migrations no matter what their project's coding
standard might say!
> If anything, mrg's example fits that mold.
I still don't see that.
To me mrg's example is pure C89.
There's no newer language features needed. It compiles error-free with
GCC-14 (and GCC-15) with "-stc=c89", so there's no need for mixing with
"-stdc=c99 -fpermissive".
However his reply implies there's code with what GCC-14 considers to be
mixed language requirements and thus requires "-stdc=c99 -fpermissive"
(or whatever is required for the language level).
> 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.
It's not the earlier compiler's fault -- it probably did issue a warning.
But indeed C23 is a new language with new rules, and GCC-14 and Clang
are pushing it like there's never been a C89.
BTW, nobody has mentioned a potential elephant in the room, and perhaps
it is only fictional, at least on NetBSD. It is the case of system
headers that might not be backwards compatible enough to allow running a
compiler with "-stdc=c89". In theory they should use __STDC_VERSION__,
but do they all?
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgppui7Ys43kK.pgp
Description: OpenPGP Digital Signature