On 5/2/24 04:01, Florian Weimer wrote:
* Alan Coopersmith:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042
This change:
#ifndef __cplusplus
+#if __STDC_VERSION__ >= 199901L
+#include
+#else
typedef enum
{
false = 0,
* Alan Coopersmith:
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042
This change:
#ifndef __cplusplus
+#if __STDC_VERSION__ >= 199901L
+#include
+#else
typedef enum
{
false = 0,
true
} bool;
+#endif
# define
On 2024-05-01 05:33, Nick Bowler wrote:
Just configure with CFLAGS=-std=c99 or whatever.
I was thinking along the same line. We should keep things simple. Using
CFLAGS is a documented way to specify the compiler flags, and ideally
there would be no need for a new feature in this area.
On 2024-04-30 21:59, Jacob Bachmeyer wrote:
> Paul Eggert wrote:
>> While we're adding to our wishlist that should also be a
>> configure-time option, not merely something in configure.ac. That
>> way, one could test a tarball's portability without having to modify
>> the source code.
This is
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
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.
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
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
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 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
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
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
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
13 matches
Mail list logo
