From: Junio C Hamano <gitster@pobox•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] 3.0: require C99 flexible-array member syntax
Date: Fri, 12 Dec 2025 21:54:14 +0900 [thread overview]
Message-ID: <xmqqqzszc13d.fsf@gitster.g> (raw)
In-Reply-To: <aTvT8A31tQFvCvtL@pks.im> (Patrick Steinhardt's message of "Fri, 12 Dec 2025 09:36:00 +0100")
Patrick Steinhardt <ps@pks•im> writes:
>> As we are pushing more and more C99 language features, let's declare
>> the historical forms of flexible array member support obsolete and
>> require C99 syntax from all compilers that want to compile Git.
>
> Is there any specific reason why this is tied to the 3.0 breaking
> changes document?
Convenience, mostly.
It is not like we weren't allowing use of an advanced syntax and
then trying to see if everybody can use it, which was perfect match
for our past "weather balloon" approach. Rather, we know that many
platforms did not know how to grok fam[] with an empty brackets, and
have workarounds fam[0] and fam[1]. This change proposes to break
the platforms that has to rely on the latter.
> So I wonder whether we should instead convert one of the sites that
> currently uses FLEX_ARRAY to use C99 flexible arrays unconditionally.
OK, that is easy enough. Or just remove it altogether and see who
screams, like the attached.
----- >8 -----
Subject: [PATCH] FLEX_ARRAY: require platforms to support the C99 syntax
Before C99 syntax to express that the final member in a struct is an
array of unknown number of elements, i.e.,
struct {
...
T flexible_array[];
};
came along, GNU introduced their own extension to declare such a
member with 0 size, i.e.,
T flexible_array[0];
and the compilers that did not understand even that were given a way
to emulate it by wasting one element, i.e.,
T flexible_array[1];
As we are using more and more C99 language features, let's see if
the platforms that still need to resort to the historical forms of
flexible array member support are still there, by forcing all the
flex array definitions to use the C99 syntax and see if anybody
screams (in which case reverting the changes is rather easy).
Signed-off-by: Junio C Hamano <gitster@pobox•com>
---
* In the longer term, I'd love to import the fortified memcpy()
invented for the Linux kernel project that takes advantage of
advanced compiler features like __builtin_object_dynamic_size()
and friends, and use of C99 flexible array syntax is a good first
step to make it happen.
git-compat-util.h | 33 ++-------------------------------
1 file changed, 2 insertions(+), 31 deletions(-)
diff --git c/git-compat-util.h w/git-compat-util.h
index 398e0fac4f..8e3f3a58a3 100644
--- c/git-compat-util.h
+++ w/git-compat-util.h
@@ -38,37 +38,8 @@ struct strbuf;
DISABLE_WARNING(-Wsign-compare)
#endif
-#ifndef FLEX_ARRAY
-/*
- * See if our compiler is known to support flexible array members.
- */
-
-/*
- * Check vendor specific quirks first, before checking the
- * __STDC_VERSION__, as vendor compilers can lie and we need to be
- * able to work them around. Note that by not defining FLEX_ARRAY
- * here, we can fall back to use the "safer but a bit wasteful" one
- * later.
- */
-#if defined(__SUNPRO_C) && (__SUNPRO_C <= 0x580)
-#elif defined(__GNUC__)
-# if (__GNUC__ >= 3)
-# define FLEX_ARRAY /* empty */
-# else
-# define FLEX_ARRAY 0 /* older GNU extension */
-# endif
-#elif defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
-# define FLEX_ARRAY /* empty */
-#endif
-
-/*
- * Otherwise, default to safer but a bit wasteful traditional style
- */
-#ifndef FLEX_ARRAY
-# define FLEX_ARRAY 1
-#endif
-#endif
-
+#undef FLEX_ARRAY
+#define FLEX_ARRAY /* empty - weather balloon to require C99 FAM */
/*
* BUILD_ASSERT_OR_ZERO - assert a build-time dependency, as an expression.
prev parent reply other threads:[~2025-12-12 12:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 10:16 [PATCH] 3.0: require C99 flexible-array member syntax Junio C Hamano
2025-12-12 8:36 ` Patrick Steinhardt
2025-12-12 12:54 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqqzszc13d.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox