Re: Is 'for (int i = [...]' bad for C STD compliance reasons?

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> Also, our code does not introduce a new variable in the first part
>> of "for (;;)" loop control, so even if the original lacked decl for
>> "i", the posted patch is not how we write our code for this project.
>
> Just curious: Out of preference, or for compatibility with older C
> standards?

The latter.

cc0c4297 (CodingGuidelines: spell out post-C89 rules, 2019-07-16)
adds a few "weather balloons say these are OK" together with this
exact one as "not yet allowed".  We (at least, those of us who have
enough knowledge and authority to propose changes to the guidelines)
all know that particular feature is a nice thing to use if everybody
we care about supports it [*1*].

Here is the thread that resulted in the relevant part of the
guideilne.

https://lore.kernel.org/git/CAPUEspgjSAqHUP2vsCCjqG8b0QkWdgoAByh4XdqsThQMt=V38w@mail.gmail.com/

The "another patch that tried to use it late last year" the thread
refers to is
https://lore.kernel.org/git/20181114004745.GH30222@szeder.dev/

If I am not mistaken, Carlo added gcc-4.8 CI job to catch these
recently?

Now, "Centos 6 is no longer" cannot be called a good response to
this message.  We stopped at seeing the first failure, and breakages
on other platforms were not even counted back then.  To those whose
compilers also barfed, it was sufficient that we pulled the plug
after seeing a failure on Centos 6.

But two years may be long enough for us to try again.  If we want to
pursue it, we'd need to raise a weather balloon that would break
compilers that have been happily grokking our code loudly by being
in a central place that will never be conditionally compiled out,
and is easy to back out by being in ultra-stable location.

cbc0f81d (strbuf: use designated initializers in STRBUF_INIT,
2017-07-10) is an example that Peff found and used a great such
location.

I know you are capable of reading Documentation/CodingGuidelines and
running "git blame" on it, and then use mailing list archive to dig
to find the answer, and it was a bit of disappointment to see this
was asked as a question, rather than a well researched "now after
two years, let's try this again".


[References]

*1* https://lore.kernel.org/git/xmqqlgnrq9qi.fsf@gitster.mtv.corp.google.com/