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
I installed the attached patch into Savannah master to get the ball
rolling on Autoconf supporting C23.
Most C23 compatibility gizmos are now done in Gnulib. However,
Autoconf's AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC.
Although this may cause a few backward compatibility ha
Paul Eggert 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,
Le mar. 30 avr. 2024 à 15:01, Sam James a écrit :
>
> Paul Eggert 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 *ru
> I installed the attached patch, which is less ambitious but should
> address the original problem report.
It does address the problem report and it looks good to me, thanks a lot!
It's also a bit less invasive than passing -std:c11 -Zc:__STDC__.
The manual of AC_C_VARARRAYS could mention using
> +*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
> + This ports better to MSVC, which does not support variable length
> + arrays and does not define __STDC__.
Suggestion:
```
*** AC_PROG_CC no longer tests for variable length arrays (VLAs), or
whether __STDC__ is
Antonin Décimo writes:
> Le mar. 30 avr. 2024 à 15:01, Sam James a écrit :
>>
>> Paul Eggert 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_
On 4/30/24 10:51, Paul Eggert wrote:
I installed the attached patch into Savannah master to get the ball rolling on
Autoconf supporting C23.
Most C23 compatibility gizmos are now done in Gnulib. However, Autoconf's
AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC. Although this may
On 2024-04-30 11:24, Alan Coopersmith wrote:
the biggest source of problems was not function prototypes,
but the change of "true" and "false" to no longer be acceptable lvalues,
and of "bool" to be a builtin type.
Thanks for mentioning that, as I hadn't run into that problem. I
installed the a
On Tue, Apr 30, 2024, at 2:43 PM, Paul Eggert wrote:
> On 2024-04-30 11:24, Alan Coopersmith wrote:
>> the biggest source of problems was not function prototypes,
>> but the change of "true" and "false" to no longer be acceptable lvalues,
>> and of "bool" to be a builtin type.
>
> Thanks for mentio
Thanks for the suggestion; I installed the attached. Part of the idea is
for the first line to be a complete summary.From 02f232c67156da2d353c986fd77d408db5084f79 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 30 Apr 2024 11:48:31 -0700
Subject: [PATCH] Improve VLA wording in NEWS
Thanks
On 2024-04-30 11:49, Zack Weinberg wrote:
I think we ought to prioritize giving
package authors a way to control which edition of the C standard AC_PROG_CC
will select, rather than just always using the most recent one we know about.
Yes, we could add a new macro to do that, or a new argument t
On Tue, Apr 30, 2024, at 2:53 PM, Paul Eggert wrote:
> On 2024-04-30 11:49, Zack Weinberg wrote:
>> I think we ought to prioritize giving
>> package authors a way to control which edition of the C standard AC_PROG_CC
>> will select, rather than just always using the most recent one we know about.
>
On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.
While we're adding to our wishlist that should also be a configure-time
option, not merely something in conf
On 4/30/24 12:16, Paul Eggert wrote:
On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.
While we're adding to our wishlist that should also be a configure-time
I wasn't there when the magic was written, but I would have expected
AC_PROG_CC_C89, AC_PROG_CC_C99 and possibly new AC_PROG_CC_Cx macros
to select a version of the C standard. Apparently that wasn't their
job and now they've been deprecated in 2.70.
Paul Eggert wrote:
On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are
deliberately trying
to ensure that your code continues to compile with old compilers.
While we're adding to our wishlist that should also be a
configure-time option, not mer
17 matches
Mail list logo
