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 RT_C_DECLS
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.
Howev
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 alre
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
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 configure-time
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 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 t
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
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 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
