Junio C Hamano <gitster@xxxxxxxxx> writes: > I am puzzled by this error. The assignment is the only one that > assigns a real pointer to the .finished member, and until > finish_active_slot() is called on the slot, the loop would not > leave. I would understand the error if slot->finished is used after > the function returns to the caller, but I do not think it is the > case. IOW, I am wondering if this is a mistaken compiler that needs to be told not to raise a false warning. If the motivation behind the original "do not get fooled by a reused slot still working on somebody else's request---instead return when our request is done" was indeed what I speculated, then the pointer slot->finished when we leave this function should not matter to anybody. Would the following patch make the compiler realize that we never smuggle a local variable's address out of this function via a pointer in the structure? http.c | 3 +++ 1 file changed, 3 insertions(+) diff --git c/http.c w/http.c index 229da4d148..85437b1980 100644 --- c/http.c +++ w/http.c @@ -1367,6 +1367,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)
