From: Junio C Hamano <gitster@pobox.com>
To: Beat Bolli <dev+git@drbeat.li>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "David Aguilar" <davvid@gmail.com>,
"Randall S . Becker" <randall.becker@nexbridge.ca>,
"Taylor Blau" <me@ttaylorr.com>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
"René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH v3] cache.h: auto-detect if zlib has uncompress2()
Date: Sun, 23 Jan 2022 11:18:07 -0800 [thread overview]
Message-ID: <xmqqtudu9s7k.fsf@gitster.g> (raw)
In-Reply-To: <74d35354-20a6-9cc1-3452-573460c694bd@drbeat.li> (Beat Bolli's message of "Sun, 23 Jan 2022 01:19:08 +0100")
Beat Bolli <dev+git@drbeat.li> writes:
> On 22.01.22 00:23, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> As noted in the updated commit message this approach of having an
>>> object just for this fallback function comes at the cost of some
>>> complexity, but now the compat object lives neatly in its own object.
>> I do not see any change in this patch adding costly complexity, but
>> I notice lack of one possible trick that might become problem with
>> some compilers and linkers when their zlib has uncompress2()
>> function. Let's have this graduate very early in the next cycle, to
>> see if anybody on a rarer system sees a complaint due to having to
>> deal with a totally empty object file.
>
> OpenSSL has a macro in include/openssl/macros.h to counteract exactly this:
>
> /*
> * Sometimes OPENSSL_NO_xxx ends up with an empty file and some
> compilers
> * don't like that. This will hopefully silence them.
> */
> #define NON_EMPTY_TRANSLATION_UNIT static void *dummy = &dummy;
>
> They insert it in the otherwise empty "#else" branch of conditionally
> complied code.
Between my "I recall some compilers and linkers had trouble with an
totally empty object files, and we'd better be prepared for them"
and "I didn't see any system that had such a problem during my
tests", I still lean toward "it merely shows that the problem is
rarer than the set of systems you tried", even without further
input.
But "It is a problem for which a real workaround is used in a system
that is used more widely than we are" is a clear enough evidence
that we should have one, especially the solution is so trivial.
https://github.com/openssl/openssl/pull/10425 seems to indicate that
they are moving in a direction that removes the necessity to use
this macro, by switching to tell the build system to not compile and
build a file that would become empty due to conditionals, but nobody
in the discussion seems to question the need for the macro for
portability if an otherwise empty file need to be dealt with.
Thanks.
next prev parent reply other threads:[~2022-01-23 19:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 17:13 [PATCH] cache.h: auto-detect if zlib has uncompress2() Ævar Arnfjörð Bjarmason
2022-01-17 18:27 ` Junio C Hamano
2022-01-17 18:48 ` rsbecker
2022-01-17 19:49 ` René Scharfe
2022-01-20 2:43 ` Carlo Arenas
2022-01-19 9:45 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2022-01-19 19:17 ` Junio C Hamano
2022-01-20 1:16 ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2022-01-21 23:23 ` Junio C Hamano
2022-01-21 23:44 ` rsbecker
2022-01-22 0:55 ` Junio C Hamano
2022-01-23 0:19 ` Beat Bolli
2022-01-23 19:18 ` Junio C Hamano [this message]
2022-01-24 2:54 ` [PATCH v4] compat: " Junio C Hamano
2022-01-24 9:27 ` Ævar Arnfjörð Bjarmason
2022-01-24 18:27 ` [PATCH v5] " Junio C Hamano
2022-01-24 19:07 ` Ævar Arnfjörð Bjarmason
2022-01-24 20:21 ` Junio C Hamano
2022-01-25 10:11 ` Carlo Arenas
2022-01-25 18:11 ` Junio C Hamano
2022-01-25 19:12 ` Ævar Arnfjörð Bjarmason
2022-01-26 7:23 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtudu9s7k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=davvid@gmail.com \
--cc=dev+git@drbeat.li \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=me@ttaylorr.com \
--cc=randall.becker@nexbridge.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).