On Fri, Jan 14 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> Wasn't the initial goal here to check whether we'd accidentally include >> C99? Just checking on GCC/Clang somewhere seems sufficient enough, > > What do you mean by "accidentally include"? > > The goal here is that developer build should give developer a set of > options that help the most---"not going beyond C99" is something we > want them to be checking, if able (and we have established that > users on FreeBSD are not capable). The reason we ended up with -std=gnu99 is because of this thread where Han-Wen accidentally used an unnamed structs/unions: https://lore.kernel.org/git/xmqqlf0w5bbc.fsf@gitster.g/ He then pointed out that it would be nice if CI caught this, which would have been sufficient: https://lore.kernel.org/git/CAFQ2z_NuOy+-pfSoNAYjJhS9jZCYOfoFue10=k=iyPVsPYrB3g@xxxxxxxxxxxxxx/ > Doesn't your "something like" limits the check to CI? Developers > with compilers that _can_ help ensuring that we do not go beyond C99 > should be able to do so by their local developer build. Yes, I'm suggesting that what we're trying to catch here is rare enough that that may be sufficient, and which would sidestep the issue of wasting time on trying to make this portable everywhere. The DEVELOPER=1 feature has recently gone from something I used on a wide varity on of platforms and the worst I got was notices about unknown -W flags in a couple of them, to something where recently due to -fno-common and now more widely with -std=gnu99 I've ended up having to manually blacklist it on a few boxes where it Just Worked. So maybe you think we absolutely need to spend the effort to run less portable checks like that locally if at all possible, with all the config.mak.uname etc. work that entails, if so OK. I'm just suggesting that perhaps a more practical solution is to side-step those portability issues by checking this in CI, which I think would be Good Enough on this case.
