On Mon, Jan 24 2022, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> Aside: I have not yet found such a compiler, does anyone know of one
>> that breaks? In any case doing this for good measure seems fine, just
>> wondering if we're cargo-culting a needless workaround or not.
>
> Before I started Git, I had to deal with quite a many variations of
> UNIX, all of which looked alike but behaved slightly differently,
> and I do recall seeing this exact breakage, so it is a real solution
> to a real problem, and I can see OpenSSL folks had seen the same one.
>
> If you find my experience is not Enough, I have no further words for
> you on this topic.
I wasn't alleging that this issue was a figment of someone's
imagination, but probing for whether it was a current issue or
not. I.e. it could have been something that only mattered in the GCC 2.x
era, and OpenSSL was still carrying.
But as Carlo notes downthread it's to do with ISO C strictness and
-Wempty-translation-unit. So we'd have caught it under DEVELOPER=1, but
due to the recent over-strictness of DEVELOPER I'd disabled it on the
test boxes involved, so I didn't spot that.
> If the question is "name a compiler that breaks and is *still* in
> active use", then the answer would be fuzzy (it depends on the
> definition of "in active use"), but is useful to find out.
But as to how to deal with it this is good enough for now, but perhaps
we'll consider something like this for a future compat/*.c addition:
$ file compat/blah.c
compat/blah.c: empty
$ diff --git a/Makefile b/Makefile
index 5da099e8a16..62ec13c72fd 100644
--- a/Makefile
+++ b/Makefile
@@ -571 +571 @@ COMPAT_CFLAGS =
-COMPAT_OBJS =
+COMPAT_OBJS = compat/blah.o
@@ -2604,0 +2605 @@ endif
+compat/blah.o: EXTRA_CPPFLAGS += -Wno-empty-translation-unit
That will compile cleanly on GCC and Clang with DEVELOPER=1, which of
course may leave some other strictly ISO C compiler unsatisfied.
