Ben Peart <peartben@xxxxxxxxx> writes:
>> If this patch can survive a few releases without complaint,
>> then we can feel more confident that designated initializers
>> are widely supported by our user base. It also is an
>> indication that other C99 features may be supported, but not
>> a guarantee (e.g., gcc had designated initializers before
>> C99 existed).
>
> Correct. MSVC also supports designated initializers but does not
> fully support C99.
Thanks for a datapoint.
Just so that people do not misunderstand, it is not our goal to
declare that now you need a fully C99 compiler to build Git.
When deciding what shell scripting tools with what options in our
scripted Porcelains and tests, we use POSIX.1 as a rough guideline.
We say "let's not use this, as it is not even in POSIX" but we never
say "use of it is OK because it is in POSIX", and we sometimes even
say "even it is in POSIX, various implementation of it is buggy and
it does not work properly in practice" to certain things [*1*].
C89 has been the base of such a guideline for our C programs, and
people must not to view this patch as an attempt to raise the base
to C99. It is rather an attempt to see how far we can safely raise
the base by checking some selected useful new features [*2*] that we
have had occasions to wish that they were available, and designated
initializer for structure fields is one of them.
We may find out that, after starting with "C89, plus this and that
feature that are known to be commonly supported", the guideline may
become more succinct to say "C99, minus this and that feature that
are not usable on some platforms", if it turns out that majority of
the systems that are not fully C99 have all of the things we care
about. We do not know yet, and we are only at the beginning of the
journey to find it out.
[Footnote]
*1* Like `backtick` command substitutions that is very hard to make
them nest properly and impossible to mix portably with quoting.
*2* New, relative to our current practice, that is.
