From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org, Ramsay Jones <ramsay@ramsayjones.plus.com>
Subject: Re: [PATCH 3/3] http: support CURLOPT_PROTOCOLS_STR
Date: Mon, 16 Jan 2023 08:05:56 -0800 [thread overview]
Message-ID: <xmqqzgaicvmj.fsf@gitster.g> (raw)
In-Reply-To: <230116.86edruzk5m.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Mon, 16 Jan 2023 14:06:50 +0100")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> +#define GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR (LIBCURL_VERSION_NUM >= 0x075500)
> +#if GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR
> +#define GIT_CURLOPT_REDIR_PROTOCOLS_STR CURLOPT_REDIR_PROTOCOLS_STR
> +#define GIT_CURLOPT_PROTOCOLS_STR CURLOPT_PROTOCOLS_STR
> +#else
> +#define GIT_CURLOPT_REDIR_PROTOCOLS_STR 0
> +#define GIT_CURLOPT_PROTOCOLS_STR 0
> #endif
I find it a bit ugly that CURLOPT_* being used are all non-zero, but
it may be true in practice.
> diff --git a/http.c b/http.c
> index e529ebc993d..3224e897f02 100644
> --- a/http.c
> +++ b/http.c
> @@ -933,24 +933,22 @@ static CURL *get_curl_handle(void)
> curl_easy_setopt(result, CURLOPT_MAXREDIRS, 20);
> curl_easy_setopt(result, CURLOPT_POSTREDIR, CURL_REDIR_POST_ALL);
>
> -#ifdef GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR
> - {
> + if (GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR) {
> struct strbuf buf = STRBUF_INIT;
> ...
> + } else {
> + curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS,
> + get_curl_allowed_protocols(0, NULL));
> + curl_easy_setopt(result, CURLOPT_PROTOCOLS,
> + get_curl_allowed_protocols(-1, NULL));
> }
> -#else
> - curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS,
> - get_curl_allowed_protocols(0, NULL));
> - curl_easy_setopt(result, CURLOPT_PROTOCOLS,
> - get_curl_allowed_protocols(-1, NULL));
> -#endif
I somehow find the above over-engineered solution looking for a
problem. Conditional compilation might be ugly, but what is uglier
is a conditional compilation hidden behind what pretends to be a
runtime conditional but gets optimized away at compile time. Also,
when the non _STR variant changes status from deprecated to removed,
the code will cease to build, so I am not sure if the above is the
whole story. You'd also need dummy definitions for them when the
version of cURL is advanced enough.
It is true that with the above we will always pass both sides to the
compiler, which may be an upside, but at the same time doesn't it
make it harder to notice and remove the support of the older side
once the time comes?
Thanks.
next prev parent reply other threads:[~2023-01-16 16:09 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-14 3:47 [PATCH] ci: do not die on deprecated-declarations warning Junio C Hamano
2023-01-14 14:29 ` Ramsay Jones
2023-01-14 15:14 ` Ramsay Jones
2023-01-14 16:13 ` Junio C Hamano
2023-01-14 14:47 ` Jeff King
2023-01-14 14:57 ` Jeff King
2023-01-14 16:15 ` Junio C Hamano
2023-01-14 17:15 ` Jeff King
2023-01-15 6:59 ` Junio C Hamano
2023-01-15 20:08 ` Jeff King
2023-01-15 21:38 ` Junio C Hamano
2023-01-14 16:55 ` Junio C Hamano
2023-01-15 7:02 ` Junio C Hamano
2023-01-15 20:09 ` Jeff King
2023-01-15 20:10 ` [PATCH 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-15 20:54 ` Ramsay Jones
2023-01-15 23:13 ` Jeff King
2023-01-15 23:49 ` Jeff King
2023-01-15 20:10 ` [PATCH 2/3] http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION Jeff King
2023-01-15 21:11 ` Ramsay Jones
2023-01-15 21:45 ` Junio C Hamano
2023-01-15 23:17 ` Jeff King
2023-01-15 20:12 ` [PATCH 3/3] http: support CURLOPT_PROTOCOLS_STR Jeff King
2023-01-15 21:37 ` Ramsay Jones
2023-01-15 23:22 ` Jeff King
2023-01-16 13:06 ` Ævar Arnfjörð Bjarmason
2023-01-16 16:05 ` Junio C Hamano [this message]
2023-01-16 16:26 ` Junio C Hamano
2023-01-16 17:23 ` Jeff King
2023-01-16 17:27 ` Jeff King
2023-01-17 3:03 ` [PATCH v2] avoiding deprecated curl options Jeff King
2023-01-17 3:04 ` [PATCH v2 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-17 3:04 ` [PATCH v2 2/3] http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION Jeff King
2023-01-17 3:04 ` [PATCH v2 3/3] http: support CURLOPT_PROTOCOLS_STR Jeff King
2023-01-18 1:03 ` [PATCH v2] avoiding deprecated curl options Ramsay Jones
2023-01-14 14:56 ` [PATCH] ci: do not die on deprecated-declarations warning Jeff King
2023-01-16 0:39 ` Ramsay Jones
2023-01-16 17:13 ` Jeff King
2023-01-14 17:13 ` [PATCH v2] " Junio C Hamano
2023-01-14 17:17 ` Jeff King
2023-01-17 3:03 ` [PATCH 1/3] http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Jeff King
2023-01-17 3:04 ` Jeff King
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=xmqqzgaicvmj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=ramsay@ramsayjones.plus.com \
/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).