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

Antonin Décimo <[email protected]> Tue, 30 Apr 2024 15:09:14 -0300
Newsgroups gmane.comp.sysutils.autoconf.general
Message-ID <CACCWBSA7Mj5sA-TJks=EbOAx+Nik3f1tYju+oyy1iA0kLE+zBg@mail.gmail.com>
Le mar. 30 avr. 2024 à 15:01, Sam James <[email protected]> a écrit :
>
> Paul Eggert <[email protected]> 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