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? 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.) Obviously GCC (and Clang) and the C standards (especially C11, C17, even C99) and their backwards compatability, combined with defaulting to the newest level, haven't made it easy to avoid such confusion. How many packages do you think there are that are really like that though -- i.e. ancient legacy in places but also strictly needing a few newer features at the same time? What happens if you do try to build them with just "-std=gnu90"? I.e. where's the bulk of the problem? I'm guessing it's easier to fix the old warts and then just get on with using "-std=gnu17" or whatever is appropriate. BTW, I would still very strongly recommend passing "-std=gnu99" (or maybe "-std=gnu17") along with "-fpermissive" though -- I've seen UB result from some legacy code compiled for C23 even without any warnings given (via valgrind, though IIRC the compiler was Clang in that case), and then work fine when the compiler was told to back off. > it's not enough to try to force everyone to c89. No, not "everyone" -- just those packages which need it until/unless they are fixed properly. All other packages which do not already provide their own "-std=" option should still get something like "-std=gnu99" (or maybe "-std=gnu17") by default. Of course if something really needs "-fpermissive" then that should be added as well, though hopefully those are few and far between. Unfortunately Clang on macos is a bit more difficult to deal with because it silently accepts "-fpermissive" but does not act on it, and even "-std=c89" (or -ansi) doesn't disable the errors (it does on FreeBSD, but not macos). On FreeBSD Clang-19 starts to behave like on macos though (at least from ports -- no idea what it will do as a native compiler if/when they upgrade to it). Clang does have "-Wno-everything" though, which I think is suitable enough for pkgsrc and what I've used on my macos systems and what I've recommended in this forum be used for pkgsrc with Clang. Clang still needs "-std=gnu99" or whatever is appropriate to avoid introducing UB to some legacy code. > the best solution, imo, is to fix the code, but we all have > priorities that matter and i'm not fixing eg, tinyfugue's > method of testing for symbols. Indeed. -- 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:
pgpF2uE7DEKFb.pgp
Description: OpenPGP Digital Signature