On Wed, Oct 11, 2023, at 3:43 AM, Niels Möller wrote:
> Niels Möller <nisse@xxxxxxxxxxxxxx> writes:
>
>> Updated patch below.
>
> How do we move this forward? I think we first need to settle the
> user-visible part, i.e., how AC_C_STANDARD_VERSION should work
...
> Latest patch aims for the following, which seems reasonable to me:
>
> * Single argument, white-space separated list of C language
> versions, in order of preference. Known versions being c89, c99,
> c11 (upper- or lower-case).
Do we want "in order of preference" or do we want "of all the entries
in the list, pick the most recent edition that the compiler supports"?
I can see arguments either way. Bob, do you have an opinion?
I think the macro should accept four-digit years (c1989, c1999, c2011)
as well as two-digit years, and I think "c90" (and "c1990") should be
recognized as a synonym for "c89". Maybe it should also accept bare
numbers?
Support for C17 and C24 is abstractly desirable as well, but since
Autoconf doesn't currently know how to probe for those editions, it
can wait until we do add the probes.
> Default behavior is unchanged, and equivalent to
>
> AC_C_STANDARD_VERSION([c11 c99 c89])
Yes.
> * Error on unknown version, error on empty (space-only) argument.
Yes.
Because Autoconf *used* to support this many years ago, if someone
puts the word "traditional" in the list, they should get a custom
error message saying that Autoconf does not support traditional C
compilers anymore. (We only *intentionally* dropped support in commit
8b5e2016c7ed2d67f31b03a3d2e361858ff5299b, which is post-2.71, but GCC
dropped support for -traditional mode in 2003, so I suspect configure
scripts haven't really worked with traditional compilers for a long
time, and I don't think it's important to be specific about *when*
Autoconf stopped supporting them in this error message. People can
read through NEWS and/or the commit history if they want to know.)
> * Error if used after AC_PROG_CC, or used multiple times.
I'm not sure if it should *error*. We have AC_BEFORE, which is
documented as being for this kind of thing, and it just warns.
>(and if that's a good name).
Internally, the terminology is "STDC_EDITION", and I like "edition"
because it emphasizes that it's not the *compiler's* version number
we're talking about. Since the macro takes a list, it might make
more sense to have the name be in the plural: AC_something_EDITIONS.
Historically, we had AC_PROG_CC_{C89,C99,STDC,TRADITIONAL} that
treated "select this standard edition" as a property of the compiler,
but those are all obsolete and more recently we have been naming "find
out if the compiler supports this feature of C" macros in the AC_C_
namespace instead.
So I propose that the name should be either AC_C_STDC_EDITIONS or
AC_PROG_CC_STDC_EDITIONS, and I slightly prefer the former. Does
anyone have a strong opinion here?
Your actual code changes look fine to me as far as they go, but
they're not complete. Let me run down a checklist of additional
things we need before the patch is ready to be reviewed in detail:
* If configure.ac has AC_C_STANDARD_VERSION([c99]) and the compiler
only supports C89, ./configure should error out (use AC_MSG_ERROR).
Analogously for any other "compiler is too old for this" situation.
* If the compiler only supports *newer* editions than the newest one
in the list, on the other hand, I think ./configure should issue a
warning (AC_MSG_WARN), select the closest edition possible, and
proceed. Does anyone disagree with that? Bob?
* Documentation.
* Tests -- most importantly, a test that, if you say
AC_C_STDC_EDITIONS([c89]) or AC_C_STDC_EDITIONS([c99]),
the compiler is put into the mode you asked for, even if
it supports newer editions, since that's the whole point
of the feature.
If the C compiler on the system that's running the test does
not support multiple editions of the C standard, the test should
be skipped (AT_SKIP_IF).
Please write as many more tests as you can think of.
* An analogous macro for C++ is not strictly necessary, but shouldn't
be too hard to add and people are definitely going to want it.
Don't bother with ObjC(++) for now, as there isn't exactly a
*standard* for those; we'd need input from people who use those
languages on what would actually be useful to them, and it can wait.
> I'd be happy to sign FSF copyright assignment forms, if required.
I think this is big enough, or will be, that we do need that, yes.
Please follow the instructions in the form at
<https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future>.
Thank you for your work so far!
zw
