On Thu, Dec 09, 2021 at 01:05:44PM +0100, Ævar Arnfjörð Bjarmason wrote: > > + > > +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter clang7,$(COMPILER_FEATURES))),) > > +DEVELOPER_CFLAGS += -std=gnu99 > > +endif > [...] > > This approach looks good & the rationale make sense. > > I mentioned in [1] that this might be a bad idea because: > > And as you note it's not only that older or non-gcc non-clang compilers > may not understand this at all, but are we getting worse behavior on > modern versions of those two because they're forced into some 20 year > old C99 standard mode, instead of the current preferred default? > > But from some short testing of GCC it will generate the exact same > <file>.s regardless of -std=* option, so I think this indeed only > impacts the warnings we'll emit. So pinning this seems to categorically > be a good thing. Thanks for looking into that. The thought crossed my mind, too, but I didn't have any actual data. I think some of this is due to the standard committee keeping backwards compatibility. I.e., it's unlikely for there to be a case where the N standard says "you must do X", and N+1 says "that's dumb, you can do Y instead". Usually it is about new features that were syntactically invalid or created undefined behavior in version N. > A bad thing about this is that we'll explicitly avoid happy accidents > where we start relying on some newer C standard, and discover N releases > later that it was no big deal, and can thus just use that feature. > > On the other hand having this means less back & forth churn of adding > such a dependency only to find it breaks on one of our platforms > etc. Overall I think this makes sense, just say'n. Right. I think it forces us to be more deliberate, but that's probably OK. > I don't think this needs to change, but FWIW this would benefit from the > same sort of "let's just compile it" step as [2]. I.e. I think you'll > find that we could just check the exit code of: > > $(CC) -E -std=gnu99 - </dev/null > > This works on GCC/Clang, and will die on xlc/suncc, and I assume any > other compiler that doesn't grok this. But I think it's better to avoid > a $(shell) here just for that, and any such change can wait until we > have some proper "compile this once and cache it" probing for > config.mak.dev. You'd lose one property that the version-check has, which is that we don't ever _upgrade_ to gnu99 from gnu89. I'm not sure how important that is, though. It would have been bad if we took something like brian's c99 patch, and developers and CI both failed to realize that it was breaking the out-of-the-box build for older compilers (because behind the scenes they were getting -std=gnu99 that non-developers do not). But now that we've decided on that direction anyway, I'm not sure there's anything left to be learned. -Peff
