At Fri, 24 Oct 2025 11:00:28 -0400, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote: Subject: Re: Fixing configure failures from newer gcc > > On Mon, 20 Oct 2025 at 14:13, Greg A. Woods <woods%planix.ca@localhost> wrote: > > > > I would argue that is the old way. It's also not really the problem. > > How is it "the old way". "old" as in prior to GCC-14 (and Clang-NN where NN may vary depending on which platform you are using it on) I'm calling k&r C "ancient", and pre-C23 C "old". :-) I'll shimmy further out on this limb and say C23 C shouldn't really be allowed to be called C, and it is definitely not "Plain C". It has broken backward compatability in far too many ways. Perhaps it could be called "New C" or something like that. They should have eliminated UB at the same time, but I think there are too many compiler vendors controlling the committee. > I think you just mounted an argument for specifying -std=$((--c23)) > (c17?) as that is the last known point where these projects > successfully built. Indeed, and that's what I would prefer, except that's not allowed by GCC-14. It only allows "-std=c89" (or a maze of error-specific options) to turn off errors related to ancient constructs allowed by C89/C90. > 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 If a project wants to support being buildable with an older compiler? I suspect (I haven't read the rationale) that __STDC_VERSION__ is in the standard primarily in order to allow system vendors to make their headers compatible with older compilers, or indeed with newer compilers running in compatability mode. NetBSD's headers contain many such examples. For example it allows one to create a <stdbool.h> that works even if there's no "bool" or "_Bool" keyword: #if (__STDC_VERSION__ - 0) < 202311L # if (__STDC_VERSION__ - 0) < 199901L # define bool int # else # define bool _Bool # endif # define true 1 # define false 0 #endif Of course normally a project wouldn't use __STDC_VERSION__ for anything -- unless the maintainers were real masochists and wanted to mix new language features while still supporting older compilers. I've done that, e.g. for <stdbool.h>. :-) > > > 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. Perhaps I should have said "To GCC-14 mrg's example is pure C89." I.e. as per above it must be considered pure C89 when compiled with GCC-14 or newer because of GCC-14's ultra-conservative (and easier to implement) approach. Clang, and especially Clang-on-macos takes an even stricter point of view. Ideally I would think a new compiler wouldn't take the liberty to add any more errors when run with "-std=c17" than any previous version that defaulted to compiling for C17 did. I had hoped pkgsrc could just set "-std=c17" for things that didn't already have a "-std=" option and get on with it, but that doesn't mitigate the new errors -- only "-std=c89" does. I.e. since the errors are about ancient constructs the GCC-14 way to implement things is to require "-std=c89" and nothing newer. This totally avoids the introduction of any new incompatible keywords and hopefully also avoids triggering new UB too. It's the view that "If your code contains ancient stuff the compiler cannot assume _anything_ -- it must be compiled as if it is 1989, not last year." I would say GCC is strictly wrong to do this because (IIUC) C17 didn't permit the compiler to throw errors for C89 constructs so "-std=c17" still shouldn't throw errors, but I'm obviously not a GCC maintainer. :-) -- 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:
pgpDAy5FyMMN_.pgp
Description: OpenPGP Digital Signature