git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Carlo Arenas <carenas@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org, Michael J Gruber <git@grubix.eu>
Subject: Re: [PATCH] http.c: clear the 'finished' member once we are done with it
Date: Tue, 24 May 2022 19:02:15 -0700	[thread overview]
Message-ID: <CAPUEsph5udmc7pyza0WdhXDFfHSm96Xwt3CnEiPnSDSqY6fOUg@mail.gmail.com> (raw)
In-Reply-To: <xmqqo7zmcydv.fsf@gitster.g>

Please, I apologize in advance because I am making statements way
above my paygrade and without the relevant foundation (because as I
mentioned, I looked at it briefly a while ago, and hadn't been able to
get the time to complete my analysis).

I did read all your analysis and while as Aevar pointed out, I might
be mistaken, or not making myself clear enough, it is not intentional
and if told to do so, will extract myself from this thread until I can
do a full analysis.

On Tue, May 24, 2022 at 4:19 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Is such a use of the pointer in the structure a cause for an
> undefined behaviour?

If you make an IMHO overly strict reading of the standard (which it
would seem gcc12 implementers might have done) then ANY access to a
pointer that might be out of scope is Undefined Behaviour.

gcc doesn't know what happens to the variable after it gets shipped
out of this function inside that opaque structure that is passed
around between threads in curl, so it MIGHT reasonably assume that:

1) There is a layering violation somewhere and another thread is
modifying that field to point it to a different thread local from the
same function.
2) Once it gets the value back, then it can assume that reading that
pointer might be undefined behaviour because it might be coming from a
different stack frame than ours (after all, any sane developer would
store instead a flag)
3) since the if uses a condition that is UB then it can optimize it out

I can't see any other reason why in the original code, with the if,
the warning was still being triggered, but not without it.

BTW while trying to debug gcc to find out if this is a bug or a lost
opportunity for optimization of something else, I noticed that it
would only trigger in cases where the structure was shipped outside
the function through another function, not when it was returned back
from it, for example.

I don't even have gcc-12 in the current workstation I am using, but
would prepare a machine with it and debug further if you think giving
a more complete answer is necessary.

Carlo

  reply	other threads:[~2022-05-25  2:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 18:04 [PATCH 0/2] quell a few gcc warnings Michael J Gruber
2022-05-06 18:04 ` [PATCH 1/2] dir.c: avoid gcc warning Michael J Gruber
2022-05-06 20:21   ` Junio C Hamano
2022-05-09 15:58     ` Taylor Blau
2022-05-07  6:14   ` Carlo Marcelo Arenas Belón
2022-05-06 18:04 ` [PATCH 2/2] http.c: " Michael J Gruber
2022-05-06 20:22   ` Junio C Hamano
2022-05-06 21:17     ` [PATCH] http.c: clear the 'finished' member once we are done with it Junio C Hamano
2022-05-07  5:40       ` Carlo Marcelo Arenas Belón
2022-05-07 18:42         ` Junio C Hamano
2022-05-07 19:11           ` Carlo Arenas
2022-05-23 21:58       ` Johannes Schindelin
2022-05-23 22:58         ` Junio C Hamano
2022-05-23 23:36           ` Junio C Hamano
2022-05-23 23:41           ` Johannes Schindelin
2022-05-24  0:02             ` Junio C Hamano
2022-05-24  6:31               ` Daniel Stenberg
2022-05-24 10:57                 ` Johannes Schindelin
2022-05-24 17:45                 ` Junio C Hamano
2022-05-26 14:15                   ` Daniel Stenberg
2022-05-24 11:03               ` Johannes Schindelin
2022-05-24 17:15                 ` Junio C Hamano
2022-05-24 20:16                   ` Carlo Marcelo Arenas Belón
2022-05-24 20:45                     ` Ævar Arnfjörð Bjarmason
2022-05-24 22:34                       ` Junio C Hamano
2022-05-25  9:08                         ` Michael J Gruber
2022-05-25 13:27                         ` Ævar Arnfjörð Bjarmason
2022-05-24 22:16                     ` Junio C Hamano
2022-05-24 23:19                     ` Junio C Hamano
2022-05-25  2:02                       ` Carlo Arenas [this message]
2022-05-24 20:38                   ` Ævar Arnfjörð Bjarmason
2022-05-24 22:28                     ` Junio C Hamano
2022-05-25 10:07                       ` Johannes Schindelin
2022-05-25 16:40                         ` Junio C Hamano
2022-05-06 20:41   ` [PATCH 2/2] http.c: avoid gcc warning Carlo Marcelo Arenas Belón
2022-05-09 11:22 ` [PATCH] detect-compiler: make detection independent of locale Michael J Gruber
2022-05-09 15:52   ` Junio C Hamano
2022-05-09 15:59     ` rsbecker

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPUEsph5udmc7pyza0WdhXDFfHSm96Xwt3CnEiPnSDSqY6fOUg@mail.gmail.com \
    --to=carenas@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).