At Thu, 2 Jul 2026 22:11:47 +0200, Tobias Nygren <tnn%NetBSD.org@localhost> wrote: Subject: Re: heads up RE autoconf C23 vs legacy code > > On Thu, 02 Jul 2026 15:52:51 -0400 > Greg Troxel <gdt%lexort.com@localhost> wrote: > > > I think that's figuring out how to patch scmcvs's configure.in to ask > > for C99. Or maybe it's in c89. > > I found a somewhat reasonable workaround that does not require a patch: > > CONFIGURE_ENV+= ac_cv_prog_cc_c23=no > > I will commit that unless there are better ideas. Interesting. I was looking for how to do this some time ago but never figured it out in the time I had available then. I was mislead by all the messages from AC_PROG_CC_C* and AC_PROG_CC_STDC saying they are "obsolete; use AC_PROG_CC" when AC_PROG_CC cannot do what one desires to limit the compiler to an older C. However I'm not sure it will actually work all of the time for all compilers, depending on their default language level. Autoconf's default goal is to find the latest supported standard, not to try to limit the compiler to a lower standard. It has no way to do the latter on its own. > The obvious drawback is we will have to add ac_cv_prog_cc_c29=no as well > a few years down the road. In theory. A C99 program may also need the following for some compilers: ac_cv_prog_cc_c11=no (though C11 isn't so incompatible with C99, and the current tests don't explicitly add "-std=c11" if this is not needed for the compiler, just as they don't add "-std=c99" of this is not needed for the comiler.) Note also no available Autoconf version tests for C17 so far. However note that none of this is documented as a valid known way to interact with Autoconf. W.r.t. this being a bug in Autoconf, well it depends on your goals. Autoconf's goals are to always enable the latest supported language level (for C at least). It seems the Autoconf maintainers are seriously misunderstanding the actual needs of legacy code maintainers. They seem to only be targeting new development and assuming it will want the latest possible language features, and all the GNU extensions as well -- nothing less. As-is there's no real valid way, documented or otherwise, for the configure.ac file itself to force a compiler to explicitly compile only C99, for example, other than to know exactly what option to put in CFLAGS, but this varies by compiler. There is an M4 macro, _AC_C_C99_OPTIONS, that gives all known options to enable "gnu99" in known compilers, but nothing for strict C99, and besides that's an internal-use-only M4 macro. What I've done in the past is suggest that one always set CC in configures environment using the POSIX compiler names: CC=c99 ./configure (which could then be fooled by any errant '-std=' option given later on the command line, but by default that shouldn't happen unless some compiler needs, e.g. "-std=c23" to extend its support to C23, meaning that it defaults to an older standard than the one it maximally supports) Too bad AC_LANG doesn't accept something like "C 99" or "GNU 99", etc., e.g. somewhat as it does for "Fortran" and "Fortran 77". -- 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:
pgpRiPVWMPvt0.pgp
Description: OpenPGP Digital Signature