On Mon, Jan 16, 2023 at 10:35:53AM -0800, Junio C Hamano wrote: > > The word "unleak" in the subject made me think about UNLEAK(), so this > > is a small tangent. This is exactly the kind of case that I designed > > UNLEAK() for, because the solution really is "while you are assigning to > > X, also keep a copy of the pointer in Y to be freed later". > > Yup. I was originally planning to use UNLEAK(), but it felt ugly to > UNLEAK(rev.subject_prefix), as it stores borrowed pointer sometimes > and owned pointer some other times, which is the exact reason why I > started looking for a clean way to plug this leak. So I ended up > with declaring that the member should only store a borrowed pointer. That's actually one of the nice things about UNLEAK(). It is OK to over-mark something that may or may not be allocated. > The first sentence needs to be rephrased, as it does not make much > sense to have something usually be X and always be X at the same > time (I'd just remove "always" from there). Yep, agreed. -Peff
