Re: [sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Nick Bowler]

On 2020-07-27, Zack Weinberg <INVALID.NOREPLY@gnu.org> wrote:
> URL:
>   <https://savannah.gnu.org/support/?110286>
>
>                  Summary: Make it possible to request a specific
> (non-latest)
> version of a language standard
>                  Project: Autoconf
>             Submitted by: zackw
>             Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
>                 Category: None
>                 Priority: 5 - Normal
>                 Severity: 1 - Wish
>                   Status: None
>                  Privacy: Public
>              Assigned to: None
>         Originator Email:
>              Open/Closed: Open
>          Discussion Lock: Any
>         Operating System: None
>
>     _______________________________________________________
>
> Details:
>
> Feedback on the 2.69b beta indicates that users find the new behavior of
> AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
> language standard, problematic.  Quoting
> https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :
>
>> One issue we [PostgreSQL] would like to point out is that
>> the new scheme of automatically checking for the latest
>> version of the C and C++ standards (deprecating AC_PROG_CC_C99
>> etc.) is problematic...
>>
>> [W]e have set C99 as the project standard. So checking for
>> C11 is (a) useless, and (b) bad because we don't want
>> developers to accidentally make use of C11 features and have
>> the compiler accept them silently.

I have no comments on the C++ side of things but on the C side this
request doesn't make too much sense.

As a portability tool, the goal of Autoconf and configure scripts is
to find a compiler that can successfully compile the application.

Aside from the removal of gets from the standard library (which most
C11 compilers still implement anyway) and that some language features
which were mandatory in C99 are now optional (which again, most C11
compilers implement anyway), C11 is essentially completely backwards
compatible with C99 so such a compiler should be perfectly fine for
building a C99 codebase.

AC_PROG_CC_C99 has never guaranteed that a C99 compiler will be selected,
it is "best effort" only and has always accepted C11 compilers provided
they support VLAs.  GCC has defaulted to C11 mode for the better part
of a decade now (since version 5) and AC_PROC_CC_C99 will not add any
options.

All compilers I'm aware of that support both C99 and C11 modes will
silently accept most if not all C11 features even when C99 mode is
selected by the user.  So having Autoconf select a C99 mode is probably
not going to do anything to help projects avoid modern language
features.  For the same reason it could be difficult to write a feature
test program which usefully determines that the compiler is in C99 mode
(probably the best you can do is test for specific values of the
__STDC_VERSION__ macro which is really not the Autoconf way).

If you don't want specific language constructs to be used in your
codebase the proper way to do this is with linting tools or warning
flags during development, not with portability tools like Autoconf.

For example with GCC if you want to reject new C11 syntax you can
build with the -Werror=c99-c11-compat option.  (You could even use
Autoconf to write a configure test that will automatically add this
option to CFLAGS if it is supported by the compiler.

Cheers,
  Nick