Re: Fixing configure failures from newer gcc

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

On Mon, 20 Oct 2025 at 14:13, Greg A. Woods <woods%planix.ca@localhost> wrote:

> > 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.

How is it "the old way".

I think I'm missing something.  To me, the old way, in the good old
days, was K&R vs prototypes.

> 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).

I think you just mounted an argument for specifying -std=$((--c23))
(c17?) as that is the last known point where these projects
successfully built.

> 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.)

Why? (to channel Li'l Petey)

Why would a project care about c90?
Why would a project drag around __STDC_VERSION__ baggage, when it's
never going to be built with anything older than the previous language
version or on a system older than five years?

/me wonders if #ifdef __STDC_VERSION__ is a probable cause of CVE

> 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.

NetBSD is decidedly bleeding edge compared to Debian's
long-term-support branch.  I don't see that as a problem.

(the same is true of pkgsrc.  For instance, I used pkgsrc's
xmlto/libxml2 to reproduce a bug reported in an esoteric Linux distro
- all the mainstream Linux distros were too old)

Where I think GCC did drop the ball is in not adding a -W option to
flag this earlier.

> > If anything, mrg's example fits that mold.
>
> I still don't see that.
>
> To me mrg's example is pure C89.

Context is everything.

While the code snippet might be c89; we're discussing this in 2025,
and as part of moving from c17ish to c23ish.