Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> ...  We can take
> the patch you posted and then post release we can apply the "clear
> the .finished member as we are done with the slot" fix, which is a
> good hygiene regardless of any compiler warning issue.
> ...
> At this point, my inclination is to merge these two DEVELOPER_CFLAGS
> changes before the 2.36 final gets tagged.

So, the post release longer term clean-up with log message may look
like this.

----- >8 --------- >8 --------- >8 --------- >8 -----
Subject: [PATCH] http.c: clear the 'finished' member once we are done with it

In http.c, the run_active_slot() function allows the given "slot" to
make progress by calling step_active_slots() in a loop repeatedly,
and the loop is not left until the request held in the slot
completes.

Ages ago, we used to use the slot->in_use member to get out of the
loop, which misbehaved when the request in "slot" completes (at
which time, the result of the request is copied away from the slot,
and the in_use member is cleared, making the slot ready to be
reused), and the "slot" gets reused to service a different request
(at which time, the "slot" becomes in_use again, even though it is
for a different request).  The loop terminating condition mistakenly
thought that the original request has yet to be completed.

Today's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10)
fixed this issue, uses a separate "slot->finished" member that is
set in run_active_slot() to point to an on-stack variable, and the
code that completes the request in finish_active_slot() clears the
on-stack variable via the pointer to signal that the particular
request held by the slot has completed.  It also clears the in_use
member (as before that fix), so that the slot itself can safely be
reused for an unrelated request.

One thing that is not quite clean in this arrangement is that,
unless the slot gets reused, at which point the finished member is
reset to NULL, the member keeps the value of &finished, which
becomes a dangling pointer into the stack when run_active_slot()
returns.  In finish_active_slot(), clear the finished member after
it is used to signal the run_active_slot() caller, because we know
we are done with the pointer at that point.

Also, because compilers may not be able to follow the callchain that
deep from run_active_slot() down to finish_active_slot(), clear the
finished member but make sure to limit it to the case where the
pointer still points at the on-stack variable of ours (the pointer
may be set to point at the on-stack variable of somebody else after
the slot gets reused, in which case we do not want to touch it).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 http.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/http.c b/http.c
index 229da4d148..626b4051e1 100644
--- a/http.c
+++ b/http.c
@@ -197,8 +197,10 @@ static void finish_active_slot(struct active_request_slot *slot)
 	closedown_active_slot(slot);
 	curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);
 
-	if (slot->finished != NULL)
-		(*slot->finished) = 1;
+	if (slot->finished != NULL) {
+		*slot->finished = 1;
+		slot->finished = NULL;
+	}
 
 	/* Store slot results so they can be read after the slot is reused */
 	if (slot->results != NULL) {
@@ -1367,6 +1369,9 @@ void run_active_slot(struct active_request_slot *slot)
 			select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
 		}
 	}
+
+	if (slot->finished == &finished)
+		slot->finished = NULL;
 }
 
 static void release_active_slot(struct active_request_slot *slot)
-- 
2.36.0-rc2-233-gc1d9011153