Re: [PATCH] http.c: clear the 'finished' member once we are done with it

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:

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