Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I'd like to have it too, but for context needing to add NO_UNCOMPRESS2=Y > (which Junio's punted on for the final[2]) is a much more widespread > issue of needing new post-install build tweaking than this issue that > only affects developer builds on FreeBSD. I hate it when people misrepresent what I said, even in an attempt to spite me. For the "check ZLIB_VERSION_NUM" topic, I gave you specific things that needs to be different from the version posted with reasons, fully expecting that a better version of the patch to materialize soon (knowing how proliferate you can be when you want to) to give us enough time to assess the potential damage. I wouldn't call that "punted". For this one, config.mak.dev patch WOULD only affect developer builds, which is a much better solution than overriding what their system headers want to do and force compiling with C99 mode. With the status quo with today's code, with or without the patch Dscho wants in this thread, means ANYBODY will be stopped when they attempt to build with -std=gnu99 on FreeBSD, which is a GOOD thing. The reason why it is a much better solution to PUNT on using C99 mode on FreeBSD is because this episode makes it very clear that nobody tested building anything that use basename(), dirname(), etc. with C99 mode on the platform. I do not trust such a build, even if we could work around the system header breakage. This time we got lucky and wereq stopped by a compilation error, but I have a strong suspicion that C99-only mode of compiler on this platform is not as well battle tested as their standard mode of compilation that allows C11. I simply do not think we want to waste developer's time with C99-only mode on this platform which may end up debugging the platform and not our program. Next bug that will hit us may not be so friendly to clearly break compilation. Instead, the symptom may be a subtle runtime breakage that wastes people's time. After developers who work on FreeBSD (not Git developers who uses FreeBSD) ships an updated system headers so that more programs, not just us, are built and testsd with C99-only mode, perhaps it becomes usable as a platform to catch use of language features beyond C99, like everybody else. But with such a clearly broken system headers, I do not think today's FreeBSD is ready for that. I do trust their default settings that allows C11, a lot more than C99-only compilation with the "their libgen is broken, so here is a user side workaround" patch.
