patch3.0: require C99 flexible-array member 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 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.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/BreakingChanges.adoc |  3 +++
 git-compat-util.h                  | 31 +++++++++++++++++--------------
 2 files changed, 20 insertions(+), 14 deletions(-)

On Thu, Dec 11, 2025 at 07:16:13PM +0900, Junio C Hamano wrote:

Is there any specific reason why this is tied to the 3.0 breaking changes document? I would have expected that we introduce this change via a test balloon like we usually do for new C features that we haven't used before. And we already are using C99 features, so I wouldn't consider this change to be "more breaking" than any of the other C99 features we have introduced already.

So I wonder whether we should instead convert one of the sites that currently uses FLEX_ARRAY to use C99 flexible arrays unconditionally. On the other hand we don't really gain much by doing that, as it is just as easy to adapt the FLEX_ARRAY definitions to unconditionally use C99 flexible arrays. Both would boil down to a couple lines of changes, only.

If we see that any platform out there doesn't support this feature we can still roll back and maybe tie it to Git 3.0.

Thanks!

Patrick

Patrick Steinhardt <ps@pks.im> writes:

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.

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(-)