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

> Æ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/