On Fri, Apr 15 2022, Junio C Hamano wrote: > Carlo Arenas <carenas@xxxxxxxxx> writes: > >> this would be IMHO a better fix than the one currently queued in >> ab/http-gcc-12-workaround and indeed squashes the warning with the gcc >> 12 version that is likely to be released with Fedora 36, > > That is an excellent news, as ... > >> but notice >> that it was proposed before[1] and apparently didn't work with the >> version of the compiler that Ævar was using at that time, as >> documented in the commit message. > > ... I was the one who suggested it, and I remember that it didn't > work for Ævar back then. If the problem with the version Ævar had > is no longer there, that does sound like a good thing. 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. I don't know what version of GCC 12 Carlo is using, but I'm using it built from its main branch this week, and it warns on that "if (slot->finished == &finished)" suggestion. I don't understand what you think you're gaining from: if (slot->finished == &finished) slot->finished = NULL; That you don't get from: slot->finished = NULL; I.e. the assignment earlier in the function is unconditional, why wouldn't the clearing of the data correspond to that assignment and clear it unconditionally? If it's imagined that we have parallel assignments of the "finished" member wouldn't that check/assignment be racy?
