Re: [PATCH v2 1/1] git-compat-util: add a test balloon for C99 support

On 2021-11-16 at 12:19:43, Jeff King wrote:

On Tue, Nov 16, 2021 at 02:12:41AM +0000, brian m. carlson wrote:

quoted

The C99 standard was released in January 1999, now 22 years ago.  It
provides a variety of useful features, including variadic arguments for
macros, declarations after statements, variable length arrays, and a
wide variety of other useful features, many of which we already use.

I like the idea of being able to assume C99. And I know this list is
just "here are some things we could do". But I'd like to express caution
over variable length arrays. We've already had problems with alloca()
causing stack exhaustion, and VLAs are basically the same thing. And the
worst part is there's no way to recover; you just get a segfault.

Since it looks like I'll be doing a v3, I'll reroll without that.

quoted

diff --git a/Makefile b/Makefile
index 12be39ac49..893d533d22 100644
--- a/Makefile
+++ b/Makefile

@@ -1204,7 +1204,7 @@ endif
 # Set CFLAGS, LDFLAGS and other *FLAGS variables. These might be
 # tweaked by config.* below as well as the command-line, both of
 # which'll override these defaults.
-CFLAGS = -g -O2 -Wall
+CFLAGS = -g -O2 -Wall -std=gnu99
 LDFLAGS =
 CC_LD_DYNPATH = -Wl,-rpath,
 BASIC_CFLAGS = -I.

Do most compilers understand -std=gnu99? It seems like we're breaking
the out-of-the-box build for everything that isn't gcc or clang.

I'm pretty sure -Wall is GCC- and clang-specific, as is -Wl,-rpath, so I
think we've already crossed that bridge.  There are places in
config.mak.uname where they're specifically overridden for that reason.

-std=gnu99 (or -std=c99) is absolutely required for sparse, though,
since it defaults to C89 (at least in CI).

I understand that older versions of gcc (prior to 5.1.0, from my
digging) default to gnu89, and so they would be broken _without_ this.
So it is a tradeoff one way or the other. But somehow this seems
backwards to me. We should assume that modern compilers support C99 out
of the box, and put the burden on older ones to trigger C99 support in
whatever non-portable way they need.

We'll have to adjust the CI job that builds with GCC 4.8, but I can do
that.  I just am not eager to hear complaints from people that it
doesn't work out of the box, especially since CentOS 7 is going to hit
this case.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA