Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Paul Eggert]

On 2024-04-26 08:10, Zack Weinberg wrote:


I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
test fails, and __STDC_NO_VLA__ was not defined by the compiler,
then AC_DEFINE([__STDC_NO_VLA__], 1)


Although the basic strategy sounds reasonable, AC_PROG_CC is documented 
to operate by setting compiler options not via AC_DEFINE, so presumably 
this should put -D__STDC_NO_VLA__ into $CC rather than use AC_DEFINE.


I installed the attached patch, which is less ambitious but should 
address the original problem report. The attached patch doesn't preclude 
your suggestion, which can be done later as needed.From e9fee73dba5d2156abc48734b5a9faff89dcdc11 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 25 Apr 2024 14:47:20 -0700
Subject: [PATCH] Port better to MSVC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problems reported by Antonin Décimo in:
https://lists.gnu.org/r/autoconf/2024-04/msg1.html
* lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS):
Do not test the value of __STDC__.
(_AC_C_C99_TEST_MAIN): Do not test for VLAs.
(_AC_C_C11_OPTIONS): Also test -std:c11.
---
 NEWS  |  7 +++
 doc/autoconf.texi |  9 +++--
 lib/autoconf/c.m4 | 17 +++--
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index 01a058aa..3d968c4c 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,13 @@ GNU Autoconf NEWS - User visible changes.
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Backward incompatibilities
+
+*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
+  This ports better to MSVC, which does not support variable length
+  arrays and does not define __STDC__.  Although C99 requires VLAs,
+  they are optional in C11 and later.  Programs can use AC_C_VARARRAYS
+  and __STDC_NO_VLA__ to use VLAs if available.
 
 * Noteworthy changes in release 2.72 (2023-12-22) [release]
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 186c033b..0fd82056 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7444,9 +7444,14 @@ the C standard, and @samp{no} if the compiler does not support compiling
 standard C at all.
 
 The tests for standard conformance are not comprehensive.  They test the
-values of @code{__STDC__} and @code{__STDC_VERSION__}, and a
+value of @code{__STDC_VERSION__}, and a
 representative sample of the language features added in each version of
-the C standard.  They do not test the C standard library, because the C
+the C standard.  They do not examine @code{__STDC__}
+because some compilers by default leave it undefined.
+They do not test for variable-length arrays,
+a C99 feature that was made optional in C11;
+if you need to use this feature when available, use @code{AC_C_VARARRAYS}.
+They do not test the C standard library, because the C
 compiler might be generating code for a ``freestanding environment''
 (in which most of the standard library is optional).  If you need to know
 whether a particular C standard header exists, use @code{AC_CHECK_HEADER}.
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index d8eab7bb..d410f8bc 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1120,12 +1120,8 @@ AC_DEFUN([_AC_C_C89_TEST_GLOBALS],
 [m4_divert_text([INIT_PREPARE],
 [[# Test code for whether the C compiler supports C89 (global declarations)
 ac_c_conftest_c89_globals='
-/* Does the compiler advertise C89 conformance?
-   Do not test the value of __STDC__, because some compilers set it to 0
-   while being otherwise adequately conformant. */
-#if !defined __STDC__
-# error "Compiler does not advertise C89 conformance"
-#endif
+/* Do not test the value of __STDC__, because some compilers define it to 0
+   or do not define it, while otherwise adequately conforming.  */
 
 #include 
 #include 
@@ -1337,13 +1333,12 @@ ac_c_conftest_c99_main='
 
   ni.number = 58;
 
-  int dynamic_array[ni.number];
-  dynamic_array[0] = argv[0][0];
-  dynamic_array[ni.number - 1] = 543;
+  // Do not test for VLAs, as some otherwise-conforming compilers lack them.
+  // C code should instead use __STDC_NO_VLA__; see Autoconf manual.
 
   // work around unused variable warnings
   ok |= (!success || bignum == 0LL || ubignum == 0uLL || newvar[0] == '\''x'\''
-	 || dynamic_array[ni.number - 1] != 543);
+	 || ni.number != 58);
 '
 ]])])
 
@@ -1553,6 +1548,7 @@ m4_define([_AC_C_C99_OPTIONS], [
 # shell quotes around the group.
 #
 # GCC, Clang-std=gnu11
+# MSVC  -std:c11
 #
 # For IBM XL C for AIX V16.1 or later, '-std=gnu11' should work if
 # the user configured with CC='xlclang'.  Otherwise, do not try
@@ -1562,6 +1558,7 @@ m4_define([_AC_C_C99_OPTIONS], [
 # _Noreturn, which is a win.
 m4_define([_AC_C_C11_OPTIONS], [
 -std=gnu11
+-std:c11
 ])
 
 
-- 
2.40.1

C23 support in Autoconf

[Paul Eggert]

I installed the attached patch into Savannah master to get the ball 
rolling on Autoconf supporting C23.


Most C23 compatibility gizmos are now done in Gnulib. However, 
Autoconf's AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC. 
Although this may cause a few backward compatibility hassles with 
ancient packages that still use K&R C functions, C23 means these 
packages need to be changed to use function prototypes anyway.


Comments welcome.From 653956f44683e1daed9827de429590bdd2e317e7 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 30 Apr 2024 10:26:50 -0700
Subject: [PATCH] AC_PROG_CC now tries C23 too

As C23 is now mostly supported by GCC, it's time for
AC_PROG_CC to prefer C23 if available.
* lib/autoconf/c.m4 (_AC_C_C23_TEST_GLOBALS, _AC_C_C23_TEST_MAIN):
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
---
 NEWS  |   4 ++
 doc/autoconf.texi |  17 +++---
 lib/autoconf/c.m4 | 129 --
 3 files changed, 139 insertions(+), 11 deletions(-)

diff --git a/NEWS b/NEWS
index 3d968c4c..952a7cc6 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,10 @@ GNU Autoconf NEWS - User visible changes.
 
 ** Backward incompatibilities
 
+*** AC_PROG_CC now prefers C23 if available.
+  C23 has removed old-style (K&R) function definitions/declarations.
+  Old-style functions should be updated to use prototypes.
+
 *** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
   This ports better to MSVC, which does not support variable length
   arrays and does not define __STDC__.  Although C99 requires VLAs,
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 0fd82056..b50d0a2b 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7434,14 +7434,15 @@ person building the package.  @xref{Preset Output Variables}.)
 If necessary, options are added to @code{CC} to enable support for
 ISO Standard C features with extensions, preferring the newest edition
 of the C standard for which detection is supported.  Currently the
-newest edition Autoconf knows how to detect support for is C11, as there is
-little reason to prefer C17 to C11, and C23 is still too new.  After calling
+newest edition Autoconf knows how to detect support for is C23.  After calling
 this macro you can check whether the C compiler has been set to accept
 standard C by inspecting the shell variable @code{ac_prog_cc_stdc}.
-Its value will be @samp{c11}, @samp{c99}, or @samp{c89}, respectively,
-if the C compiler has been set to use the 2011, 1999, or 1990 edition of
+Its value is @samp{c23}, @samp{c11}, @samp{c99}, or @samp{c89}, respectively,
+if the C compiler has been set to use the 2023, 2011, 1999, or 1990 edition of
 the C standard, and @samp{no} if the compiler does not support compiling
 standard C at all.
+(There is no special value for the 2017 edition of the C standard,
+as it is a minor revision that does not introduce new language features.)
 
 The tests for standard conformance are not comprehensive.  They test the
 value of @code{__STDC_VERSION__}, and a
@@ -9704,8 +9705,8 @@ checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether the compiler supports GNU C... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to enable C11 features... -std=gnu11
-checking how to run the C preprocessor... gcc -std=gnu11 -E
+checking for gcc option to enable C23 features... -std=gnu23
+checking how to run the C preprocessor... gcc -std=gnu23 -E
 OK
 @end example
 
@@ -26725,7 +26726,7 @@ checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether the compiler supports GNU C... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to enable C11 features... -std=gnu11
+checking for gcc option to enable C23 features... -std=gnu23
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for strings.h... yes
@@ -26757,7 +26758,7 @@ checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether the compiler supports GNU C... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to enable C11 features... -std=gnu11
+checking for gcc option to enable C23 features... -std=gnu23
 checking for number.h... yes
 checking for pi.h... yes
 @end example
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index d410f8bc..89f6a608 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1103,7 +1103,7 @@ fi[]dnl
 # Warning: each test program may only use the headers required to
 # exist in the relevant standard's *freestanding* environment, in case
 # the C compiler targets such an environment.  (Therefore, almost no
-# features of the C89/C99/C11 standard *library* are probed.  Use
+# features of the C89/C99/C11/C23 standard *library* are probed.  Use
 # AC_CHECK_HEADER, AC_CHECK_FUNC, etc. for that.)  However, these
 # programs are only com

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Sam James]

Paul Eggert  writes:

> On 2024-04-26 08:10, Zack Weinberg wrote:
>
>> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
>> Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
>> unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
>> test fails, and __STDC_NO_VLA__ was not defined by the compiler,
>> then AC_DEFINE([__STDC_NO_VLA__], 1)
>
> Although the basic strategy sounds reasonable, AC_PROG_CC is
> documented to operate by setting compiler options not via AC_DEFINE,
> so presumably this should put -D__STDC_NO_VLA__ into $CC rather than
> use AC_DEFINE.
>
> I installed the attached patch, which is less ambitious but should
> address the original problem report. The attached patch doesn't
> preclude your suggestion, which can be done later as needed.
>
> [2. text/x-patch; 0001-Port-better-to-MSVC.patch]...

Note that "or later" isn't right -- C23 makes VLAs mandatory again.


signature.asc
Description: PGP signature

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Antonin Décimo]

Le mar. 30 avr. 2024 à 15:01, Sam James  a écrit :
>
> Paul Eggert  writes:
>
> > On 2024-04-26 08:10, Zack Weinberg wrote:
> >
> >> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
> >> Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
> >> unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
> >> test fails, and __STDC_NO_VLA__ was not defined by the compiler,
> >> then AC_DEFINE([__STDC_NO_VLA__], 1)
> >
> > Although the basic strategy sounds reasonable, AC_PROG_CC is
> > documented to operate by setting compiler options not via AC_DEFINE,
> > so presumably this should put -D__STDC_NO_VLA__ into $CC rather than
> > use AC_DEFINE.
> >
> > I installed the attached patch, which is less ambitious but should
> > address the original problem report. The attached patch doesn't
> > preclude your suggestion, which can be done later as needed.
> >
> > [2. text/x-patch; 0001-Port-better-to-MSVC.patch]...
>
> Note that "or later" isn't right -- C23 makes VLAs mandatory again.

I don't think that's true… Wikipedia links to the paper modifying the
standard:

> For these reasons, we propose to make variably-modified types
> mandatory in C23. VLAs with automatic storage duration remain an
> optional language feature due to their higher implementation
> overhead and security concerns on some implementations (i.e. when
> allocated on the stack and not using stack probing).

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

Best regards,
Antonin

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Antonin Décimo]

> I installed the attached patch, which is less ambitious but should
> address the original problem report.

It does address the problem report and it looks good to me, thanks a lot!
It's also a bit less invasive than passing -std:c11 -Zc:__STDC__.

The manual of AC_C_VARARRAYS could mention using __STDC_NO_VLA__
instead, for C11 and onwards.

Best regards,
-- Antonin

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Werner LEMBERG]

> +*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
> +  This ports better to MSVC, which does not support variable length
> +  arrays and does not define __STDC__.

Suggestion:

```
*** AC_PROG_CC no longer tests for variable length arrays (VLAs), or
  whether __STDC__ is defined.  This ports better to MSVC, which does
  not support VLAs and does not define __STDC__.
```


Werner

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Sam James]

Antonin Décimo  writes:

> Le mar. 30 avr. 2024 à 15:01, Sam James  a écrit :
>>
>> Paul Eggert  writes:
>>
>> > On 2024-04-26 08:10, Zack Weinberg wrote:
>> >
>> >> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
>> >> Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
>> >> unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
>> >> test fails, and __STDC_NO_VLA__ was not defined by the compiler,
>> >> then AC_DEFINE([__STDC_NO_VLA__], 1)
>> >
>> > Although the basic strategy sounds reasonable, AC_PROG_CC is
>> > documented to operate by setting compiler options not via AC_DEFINE,
>> > so presumably this should put -D__STDC_NO_VLA__ into $CC rather than
>> > use AC_DEFINE.
>> >
>> > I installed the attached patch, which is less ambitious but should
>> > address the original problem report. The attached patch doesn't
>> > preclude your suggestion, which can be done later as needed.
>> >
>> > [2. text/x-patch; 0001-Port-better-to-MSVC.patch]...
>>
>> Note that "or later" isn't right -- C23 makes VLAs mandatory again.
>
> I don't think that's true… Wikipedia links to the paper modifying the
> standard:
>
>> For these reasons, we propose to make variably-modified types
>> mandatory in C23. VLAs with automatic storage duration remain an
>> optional language feature due to their higher implementation
>> overhead and security concerns on some implementations (i.e. when
>> allocated on the stack and not using stack probing).
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

You're right - I confused VLAs with VMTs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896#c13.

Thanks!

>
> Best regards,
> Antonin


signature.asc
Description: PGP signature

Re: C23 support in Autoconf

[Alan Coopersmith]

On 4/30/24 10:51, Paul Eggert wrote:
I installed the attached patch into Savannah master to get the ball rolling on 
Autoconf supporting C23.


Most C23 compatibility gizmos are now done in Gnulib. However, Autoconf's 
AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC. Although this may 
cause a few backward compatibility hassles with ancient packages that still use 
K&R C functions, C23 means these packages need to be changed to use function 
prototypes anyway.


Just FYI, from my experiments building the X.Org packages (a code base that
still has many bits originally written before the C89 standard) with gcc 13.2
and --std=gnu23, the biggest source of problems was not function prototypes,
but the change of "true" and "false" to no longer be acceptable lvalues,
and of "bool" to be a builtin type.

Fortunately in our cases, the patches were small & simple:

https://gitlab.freedesktop.org/xorg/app/xprop/-/commit/0d2837162ef0e54647485eee2ba4b88012fbb1b4
https://gitlab.freedesktop.org/xorg/lib/libxt/-/commit/56875344b2a62845b8a494830bfb0a5f6ed2d3d6
https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042

but I know we're not alone here with these changes, even in much newer code:

https://gitlab.freedesktop.org/cairo/cairo/-/issues/825
https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/a0b1329ee6cce22aca0c9b064fe9c136cc05d630

Of course, our experience is somewhat biased by the XORG_COMPILER_FLAGS macro
in our xorg-macros.m4 set of autoconf macros having included
-Wold-style-definition in our default CFLAGS since 2011.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: C23 support in Autoconf

[Paul Eggert]

On 2024-04-30 11:24, Alan Coopersmith wrote:

the biggest source of problems was not function prototypes,
but the change of "true" and "false" to no longer be acceptable lvalues,
and of "bool" to be a builtin type.


Thanks for mentioning that, as I hadn't run into that problem. I 
installed the attached.From 76ac2c1d735a3cc1646b452d38633ec1c6a3ce0d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 30 Apr 2024 11:41:36 -0700
Subject: [PATCH] Mention C keywords in NEWS

Thanks to Alan Coopersmith for mentioning this in:
https://lists.gnu.org/r/autoconf/2024-04/msg00011.html
---
 NEWS | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 952a7cc6..60c6dcdd 100644
--- a/NEWS
+++ b/NEWS
@@ -5,8 +5,10 @@ GNU Autoconf NEWS - User visible changes.
 ** Backward incompatibilities
 
 *** AC_PROG_CC now prefers C23 if available.
-  C23 has removed old-style (K&R) function definitions/declarations.
-  Old-style functions should be updated to use prototypes.
+  Older code may need to be updated, as C23 has removed old-style
+  (K&R) function definitions and declarations, and has new keywords
+  alignas, alignof, bool, constexpr, false, nullptr, static_assert,
+  thread_local, typeof, typeof_unqual, true.
 
 *** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
   This ports better to MSVC, which does not support variable length
-- 
2.44.0

Re: C23 support in Autoconf

[Zack Weinberg]

On Tue, Apr 30, 2024, at 2:43 PM, Paul Eggert wrote:
> On 2024-04-30 11:24, Alan Coopersmith wrote:
>> the biggest source of problems was not function prototypes,
>> but the change of "true" and "false" to no longer be acceptable lvalues,
>> and of "bool" to be a builtin type.
>
> Thanks for mentioning that, as I hadn't run into that problem. I 
> installed the attached.

Because of this class of problems, I think we ought to prioritize giving
package authors a way to control which edition of the C standard AC_PROG_CC
will select, rather than just always using the most recent one we know about.

zw

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Paul Eggert]

Thanks for the suggestion; I installed the attached. Part of the idea is 
for the first line to be a complete summary.From 02f232c67156da2d353c986fd77d408db5084f79 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 30 Apr 2024 11:48:31 -0700
Subject: [PATCH] Improve VLA wording in NEWS

Thanks to a suggestion by Werner Lemberg in:
https://lists.gnu.org/r/autoconf/2024-04/msg9.html
---
 NEWS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index 60c6dcdd..be7cb8ca 100644
--- a/NEWS
+++ b/NEWS
@@ -10,11 +10,11 @@ GNU Autoconf NEWS - User visible changes.
   alignas, alignof, bool, constexpr, false, nullptr, static_assert,
   thread_local, typeof, typeof_unqual, true.
 
-*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
-  This ports better to MSVC, which does not support variable length
-  arrays and does not define __STDC__.  Although C99 requires VLAs,
-  they are optional in C11 and later.  Programs can use AC_C_VARARRAYS
-  and __STDC_NO_VLA__ to use VLAs if available.
+*** AC_PROG_CC no longer checks __STDC__ or variable length arrays (VLAs).
+  This ports better to MSVC, which does not define __STDC__ and does
+  not support VLAs.  Although C99 requires VLAs, they are optional in
+  C11 and later.  Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
+  to use VLAs if available.
 
 * Noteworthy changes in release 2.72 (2023-12-22) [release]
 
-- 
2.40.1

Re: C23 support in Autoconf

[Paul Eggert]

On 2024-04-30 11:49, Zack Weinberg wrote:

I think we ought to prioritize giving
package authors a way to control which edition of the C standard AC_PROG_CC
will select, rather than just always using the most recent one we know about.


Yes, we could add a new macro to do that, or a new argument to 
AC_PROG_CC. Presumably it would have to be called very early.


Although the new keywords and the lack of K&R support is a problem, it's 
a problem people will have anyway as C23 spreads. So a new macro (or new 
argument) would merely be a backward compatibility hack for people who 
for some reason can't fix their old code, and the hack should be 
documented with that in mind.

Re: C23 support in Autoconf

[Zack Weinberg]

On Tue, Apr 30, 2024, at 2:53 PM, Paul Eggert wrote:
> On 2024-04-30 11:49, Zack Weinberg wrote:
>> I think we ought to prioritize giving
>> package authors a way to control which edition of the C standard AC_PROG_CC
>> will select, rather than just always using the most recent one we know about.
>
> Yes, we could add a new macro to do that, or a new argument to 
> AC_PROG_CC. Presumably it would have to be called very early.

I think a new macro would be more self-documenting and also wouldn't
interfere with the dozens of macros that AC_REQUIRE AC_PROG_CC.  Something
like

AC_C_STANDARD_EDITION([2011])
AC_PROG_CC

We could also offer

AC_C_STANDARD_EDITION([2011], [strict])

to enable use of -std=cXX instead of -std=gnuXX, or equivalent.

> Although the new keywords and the lack of K&R support is a problem, it's 
> a problem people will have anyway as C23 spreads. So a new macro (or new 
> argument) would merely be a backward compatibility hack for people who 
> for some reason can't fix their old code, and the hack should be 
> documented with that in mind.

Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.  IIRC
the PostgreSQL people wanted this.  See 
.

zw

Re: C23 support in Autoconf

[Paul Eggert]

On 2024-04-30 12:03, Zack Weinberg wrote:

Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.


While we're adding to our wishlist that should also be a configure-time 
option, not merely something in configure.ac. That way, one could test a 
tarball's portability without having to modify the source code.

Re: C23 support in Autoconf

[Alan Coopersmith]

On 4/30/24 12:16, Paul Eggert wrote:

On 2024-04-30 12:03, Zack Weinberg wrote:

Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.


While we're adding to our wishlist that should also be a configure-time option, 
not merely something in configure.ac. That way, one could test a tarball's 
portability without having to modify the source code.


Yes, it would be appreciated by distro builders and other packagers if
there was a simple way to continue to build an older code base with an
older standard even if we patch the configure.ac script and run autoreconf
with a newer autoconf release.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: C23 support in Autoconf

[Antonin Décimo]

I wasn't there when the magic was written, but I would have expected
AC_PROG_CC_C89, AC_PROG_CC_C99 and possibly new AC_PROG_CC_Cx macros
to select a version of the C standard. Apparently that wasn't their
job and now they've been deprecated in 2.70.

Re: C23 support in Autoconf

[Jacob Bachmeyer]

Paul Eggert wrote:

On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are 
deliberately trying

to ensure that your code continues to compile with old compilers.


While we're adding to our wishlist that should also be a 
configure-time option, not merely something in configure.ac. That way, 
one could test a tarball's portability without having to modify the 
source code.


Perhaps --with-C-language-standard={C89,C99,C11,C23} and a 
--with-strict-C-language to select (example) c99 instead of gnu99?



-- Jacob