On Sun, Nov 14 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > The "another patch that tried to use it late last year" the thread > refers to is > https://lore.kernel.org/git/20181114004745.GH30222@xxxxxxxxxx/ > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ The issue on CentOS 6 isn't one of incompatibility with C99, but that the version of GCC refuses to compile C99 code without -std=c99 or -std=gnu99. See [1] downthread of one of your links. But yes, it would be the first C99 feature where we have a known compiler that needs an opt-in -std=* option to support the C99 feature, I think. 1. https://lore.kernel.org/git/20190717004231.GA93801@xxxxxxxxxx/
