On Fri, Jan 14 2022, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2022-01-13 at 10:45:49, Ævar Arnfjörð Bjarmason wrote: >> [I'm aware that Jeff probably won't read this in his sabbatical, just >> replying to the relevant thread] >> >> Something neither of us considered at the time, but which is pretty >> obvious in retrospect, is that this new -std=gnu99 dosen't only apply to >> our own code, but any system and library includes that we need. >> >> Thus e.g. FreeBSD 13.0 which previously was happy to compile under >> DEVELOPER=1 will now die because its core libraries use C11-specific >> code: >> >> archive.c:337:35: error: '_Generic' is a C11 extension [-Werror,-Wc11-extensions] >> strbuf_addstr(&path_in_archive, basename(path)); >> ^ >> /usr/include/libgen.h:61:21: note: expanded from macro 'basename' >> #define basename(x) __generic(x, const char *, __old_basename, basename)(x) >> ^ >> /usr/include/sys/cdefs.h:325:2: note: expanded from macro '__generic' >> _Generic(expr, t: yes, default: no) >> ^ > > I think we had this discussion about FreeBSD before and that's why I > specifically dropped that option from the main makefile. We can either > drop that patch, or we can set it to -std=gnu11 and tell folks setting > DEVELOPER to use a system released in the last five years. I think we > can be a little stricter with what we require in the case of DEVELOPER > than we might be otherwise. I guess, yeah. As a practical matter the changes in this cycle have made DEVELOPER=1 much more fragile as a cross-platform facility. I test on various platforms/OS's (across the GCC farm), and before this cycle only AIX and Solaris were something I had to pay special attention to. Now we've got things like this breaking (by default) non-obscure things like FreeBSD. Of course I can manually set -Wall etc. which is what I previously got out of this, but before e.g. pedantic was opt-in, now an effective C-version-a-pedantic is the default, and doesn't have a tweaking knob at all. Anyway, we'll see how much of a hassle it is, and it's not too painful for me right now, so I don't think anything needs to be done in the RC period. But I wonder if the X-Y problem we're trying to solve is making sure we don't move past C99 unintentionally whether this wouldn't be better solved by dropping this -std=gnu99 approach in the Makefile, and instead just do that in one of the CI jobs (whose OS includes would be known to be C99-OK).