[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to get autoconf to respect CC="gcc -std=c89"?

From: Niels Möller
Subject: Re: How to get autoconf to respect CC="gcc -std=c89"?
Date: Sun, 08 Oct 2023 14:33:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix)

Thanks for feedback.

Paul Eggert <> writes:

> On 2023-10-07 02:03, Niels Möller wrote:
>> there's some impedance mismatch between the whitespace separated
>> list to AC_C_STANDARD_VERSION, and the comma-separated list required
>> by m4_map
> Yes, let's use the same list style for both.

Hmm, I'm not sure it's a good idea to have AC_C_STANDARD_VERSION use
that convention, i.e., AC_C_STANDARD_VERSION([c99, c89]). Do any other
user-visible autoconf macros use that convention? 

Instead, I'm trying to stick with whitespace separation for users,
AC_C_STANDARD_VERSION([c99 c89]), and use m4_map_args_w for the

Jacob Bachmeyer <> writes:

> Niels Möller wrote:
>>   AC_C_STANDARD_VERSION([c89 c99])
>> is a bit meaningless; if compiler has c89, that's what will be used, and
>> if it doesn't have c89, it won't have c99 either. 
> Free compilers may behave that way, however I have vague memories of a
> compiler that dropped support for K&R function definitions many years
> ago, long before GCC did.  Since Autoconf seeks portability, including
> to non-free systems, preferring C89 but accepting C99 is reasonable to
> express.  There may be non-free compilers out there that do not accept
> C89 but do accept C99.

I would have expected that every input that is valid c89 also is valid
c99, so that support for c99 strictly implies support for c89. But there
may be some corner case I'm not aware of.

> Some quick tests here suggest that "patsubst(patsubst([c99 c89], [c]),
> [ ], [, ])" should do that trick.

I'm trying for something a bit more complicated, which allows additional
white space as well as capital C89, but still rejects unknown versions.

> How about "error:  AC_PROG_CC_STANDARD_EDITION used after AC_PROG_CC
> invoked"?

I agree that's better. (It will still trigger also on repeated
AC_PROG_CC_STANDARD_EDITION, but maybe error message is good enough
despite that?)

Updated patch below.

BTW, I also considered changing the bare-year ids, 89/99/11, used by
_AC_PROG_CC_STDC_EDITION_TRY to C version names c89/c99/c11. I take it
the reason it's written the current way is that the edition is sometimes
expanded as lowercase, sometimes as uppercase, e.g., ac_cv_prog_cc_c$1
vs _AC_C_C$1_OPTIONS, so one would either need to switch everything to
lowercase, e.g., _AC_C_c89_OPTIONS, or do explicit m4_toupper($1) or
m4_tolower($1) to preserve current names of everything.


diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 77ff1af8..adb718f3 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1561,6 +1561,26 @@ m4_define([_AC_C_C11_OPTIONS], [
+# ----------------------------
+# Translate C version c89, c99, c11 to just the numeric year,
+# and raise an error for unknown versions.
+m4_case(m4_translit([$1], [C], [c]), [c89], 89, [c99], 99, [c11], 11,
+[m4_fatal([Unknown C language revision $1], 1)])dnl
+# -------------------------------
+# Specifies a whitespace separated list of wanted C versions, in order
+# of preference, e.g., AC_C_STANDARD_VERSION([c99 c89])
+    [m4_fatal([AC_PROG_CC_STANDARD_EDITION used after AC_PROG_CC], 1)])
+  m4_ifblank([$1], [m4_fatal([C language revision not specified], 1)])
+    [m4_map_args_w([$1],[_AC_C_CHECK_STANDARD_VERSION(], [)], [,])])
 # -------------------------------------
@@ -1623,7 +1643,8 @@ AS_IF([test "x$ac_cv_prog_cc_c$1" = xno],
 # variable ac_prog_cc_stdc to indicate the edition.
-m4_map([_AC_PROG_CC_STDC_EDITION_TRY], [[11], [99], [89]])])
+m4_define_default([_AC_C_STANDARD_VERSION_LIST], [[11], [99], [89]])

Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]