[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: Jacob Bachmeyer
Subject: Re: How to get autoconf to respect CC="gcc -std=c89"?
Date: Sun, 08 Oct 2023 22:43:42 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Niels Möller wrote:
Jacob Bachmeyer <> writes:

Niels Möller wrote:

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.

I believe that Autoconf effectively tests for declared support, so a compiler lacking a C89 mode will appear to not support C89, even if C99 is a strict superset of C89 and the compiler /does/ support C99.

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.

8<------ [test.m4]
define([convert_list], [patsubst(patsubst($1, [[Cc]]), [ +], [, ])])dnl
define([test], ["$1" -> "convert_list($1)"])dnl
test([c89 c99])
test([C99 c89])
test([C11   c89 c99])

I believe the "convert_list" macro in the above test file fulfills the translation requirements, but validation is a separate matter. Validating the result should be easier after it has been normalized to a comma-delimited list of numbers. Since I believe the proper name of the language is "C" (uppercase), normalizing case in an "unknown C language edition" error should be fine.

How about "error:  AC_PROG_CC_STANDARD_EDITION used after AC_PROG_CC

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?)

Simple solution: "error: AC_PROG_CC_STANDARD_EDITON used twice or after AC_PROG_CC invoked" :-)

-- Jacob

reply via email to

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