Re: Build failure with GCC 15 (defaults to -std=gnu23)

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Oh. Yeah. 1c27d16e6e5 was not back-patchable. And what f9a56e72 did
> in 15 and older doesn't seem to have any equivalent in C23, at least
> without going way overboard. -Wdeprecated-non-prototype was
> recognising a category of function type that no longer exists, so the
> code now falls into the more general case of
> -Wincompatible-pointer-types in C23, which you certainly wouldn't want
> to suppress. So perhaps we actually can't make any branch older than
> PostgreSQL 16 into a valid C23 program, and if that's true, I needn't
> have back-patched the <stdbool.h> change any further back than 16.
> Perhaps we should reconsider that, then. And if it can't be all the
> back-branches, we could even decide to focus just on master. Where do
> we want our C23 support to begin?

Unless somebody has a better idea than 1c27d16e6e5, it would seem
reasonable to say that we'll support C23 in v16 and later, but
to build an older branch you have to back off to an older C version.

I don't feel a need to revert those <stdbool.h> changes.
If nothing else, that saved a bit of configure runtime.

If we leave it like this, alligator will need some configuration
adjustments, and so will other BF animals when they migrate to new
gcc, and so will individual hackers when they're trying to build
old branches. A possible compromise to reduce the manual pain
level could be to adjust configure to add "-std=gnu99" or so to
CFLAGS in the pre-v16 branches, if the compiler accepts that.
(OTOH, maybe that'd cause pain for some extensions?)

regards, tom lane