All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 3/4] http.c: avoid danging pointer to local variable `finished`
Date: Tue, 24 May 2022 23:45:47 +0200	[thread overview]
Message-ID: <220524.865yluvby1.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2205242309160.352@tvgsbejvaqbjf.bet>


On Tue, May 24 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Tue, 24 May 2022, Junio C Hamano wrote:
>
>> The "clear slot->finished", by the way, is what I think is the right
>> thing to do, especially that the objective is to squelch the false
>> positive warning from a new compiler.  If there is a way to annotate
>> the line for the compiler to tell it not to warn about it, that would
>> have been even better.
>
> We could do something like this:
>
> -- snip --
> diff --git a/http.c b/http.c
> index b08795715f8a..2ac8d51d3668 100644
> --- a/http.c
> +++ b/http.c
> @@ -1365,7 +1365,14 @@ void run_active_slot(struct active_request_slot *slot)
>  	struct timeval select_timeout;
>  	int finished = 0;
>
> +#if __GNUC__ >= 12
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdangling-pointer"
> +#endif
>  	slot->finished = &finished;
> +#if __GNUC__ >= 12
> +#pragma GCC diagnostic pop
> +#endif
>  	while (!finished) {
>  		step_active_slots();
> -- snap --
>
> That's quite ugly, though. And what's worse, it is pretty unreadable, too.

Unfortunately that sort of thing is a logic error as clang, ICC and
probably others are on a mission to make __GNUC__ as useless as
possible:
https://stackoverflow.com/questions/38499462/how-to-tell-clang-to-stop-pretending-to-be-other-compilers

I think it *might* work in practice though, my local clang claims to be
gcc 4, so maybe everyone faking it stops at a low enough version?

But did you spot 9c539d1027d (config.mak.dev: alternative workaround to
gcc 12 warning in http.c, 2022-04-15)? We already disable this file-wide
in config.mak.dev, but I didn't check if the Windows code was using that
(or if you were targeting those without DEVELOPER=1).

We could move that to thake main Makefile, but then we'd have to call
detect-compiler there. I have some local patches to do something like
that if there's interest (rather, to bootstrap compilation by compiling
a C object and getting the macro values, instead of relying on that
shellscript).

  reply	other threads:[~2022-05-24 21:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  0:23 [PATCH 0/4] ci: fix windows-build with GCC v12.x Johannes Schindelin via GitGitGadget
2022-05-24  0:23 ` [PATCH 1/4] compat/win32/syslog: fix use-after-realloc Johannes Schindelin via GitGitGadget
2022-05-24 12:39   ` Johannes Schindelin
2022-05-24 20:58     ` Junio C Hamano
2022-05-24  0:23 ` [PATCH 2/4] nedmalloc: avoid new compile error Johannes Schindelin via GitGitGadget
2022-05-24  8:00   ` Ævar Arnfjörð Bjarmason
2022-05-24 15:59     ` René Scharfe
2022-05-24 20:46       ` Johannes Schindelin
2022-05-24 21:33         ` Ævar Arnfjörð Bjarmason
2022-05-24  0:23 ` [PATCH 3/4] http.c: avoid danging pointer to local variable `finished` Johannes Schindelin via GitGitGadget
2022-05-24  7:58   ` Ævar Arnfjörð Bjarmason
2022-05-24 20:06     ` Junio C Hamano
2022-05-24 21:15       ` Johannes Schindelin
2022-05-24 21:45         ` Ævar Arnfjörð Bjarmason [this message]
2022-05-24 22:38         ` Junio C Hamano
2022-05-25 10:16           ` Johannes Schindelin
2022-05-25 12:48             ` Ævar Arnfjörð Bjarmason
2022-05-24  0:23 ` [PATCH 4/4] dir.c: avoid "exceeds maximum object size" error with GCC v12.x Johannes Schindelin via GitGitGadget
2022-05-24  5:53   ` Ævar Arnfjörð Bjarmason
2022-05-24 21:05     ` Johannes Schindelin
2022-05-25 13:39       ` Derrick Stolee
2022-05-25 18:27         ` Junio C Hamano
2022-05-24 15:54 ` [PATCH 0/4] ci: fix windows-build " Jeff Hostetler

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=220524.865yluvby1.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.