On Thu, Mar 31 2022, Phillip Wood wrote: > On 31/03/2022 11:10, Ævar Arnfjörð Bjarmason wrote: >> On Wed, Mar 30 2022, Junio C Hamano wrote: >> >>> We raised the weather balloon to see if we can allow the construct >>> in 44ba10d6 (revision: use C99 declaration of variable in for() >>> loop, 2021-11-14), which was shipped as a part of Git v2.35. >>> Document that fact in the coding guidelines, and more importantly, >>> give ourselves a deadline to revisit and update. >>> >>> Let's declare that we will officially adopt the variable declaration >>> in the initializaiton [...] >> Typo: initialization. >> >>> part of "for ()" statement this winter, unless we find that a platform >>> we care about does not grok it. >> I'd think that waiting a couple of releases would be sufficient for >> this >> sort of thing. I.e. contributors to this project already have >> access/knowledge about a wide variety of compilers, especially the >> "usual suspects" (mainly MSVC) that have been blockers for using new >> language features in the past. >> So I'm in no rush to use this, and the winter deadline sounds fine >> to >> me in that regard. > > Agreed, I think it is worth waiting so we don't get into a situation > where we end up having to revert changes that are using the new > features because we discover they are not supported by a platform we > care about. > >> But on the other hand I think the likelihood that waiting until November >> v.s. May revealing that a hitherto unknown compiler or platform has >> issues with a new language feature is vanishingly small. >> >>> A separate weather balloon for C99 as a whole was raised separately >>> in 7bc341e2 (git-compat-util: add a test balloon for C99 support, >>> 2021-12-01). Hopefully, as we find out that all C99 features are OK >>> on all platforms we care about, we can stop probing the features we >>> want one-by-one like this >> Unfortunately this really isn't the case at all, the norm is for >> compilers to advertise that they support verison X of the standard via >> these macros when they consider the support "good enough", but while >> there's still a long list of unimplemented features before they're at >> 100% support (and most never fully get to 100%). >> We also need to worry about the stdlib implementation, and not just >> the >> compiler, see e.g. the %zu format and MinGW in the exchange at >> https://lore.kernel.org/git/220318.86bky3cr8j.gmgdl@xxxxxxxxxxxxxxxxxxx/ >> and >> https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@xxxxxxxxx/; > > That's a good point, it was a surprise to me that the problem is with > MinGW rather than MSVC. Yes, thanks a lot for tracking that down. I wonder if we can supply a compatibility sprintf() shim for that setup, there's nothing urgent about it, but the verbosity of the casts and PRIuMAX inline adds up, especially as we've started using size_t more widely: git grep PRIuMAX -- '*.[ch]' Either by e.g. grabbing the sprintf() shim from say gnulib, or our own shim that would intercept the "const char *format" for sprintf(), and pull a trick similar to what we do in strbuf_addftime() to rewrite the format (of a copied string) on-the-fly.
