Clemens Buchacher <drizzd@xxxxxx> writes: >> > We also didn't free() in the earlier code (because we do not know if it >> > can be freed) and leaking xmemdupz() if the function didn't return the >> > "prefix", but now you plugged the small leak. Isn't it something you >> > should advertise? >> >> Nah, the leak is not necessarily plugged in all callers anyway, so scratch >> that part. I've rewritten it like this: > > Ok. > > The only other caller, though, is cmd_ls_files(). And it would be > trivial to plug that leak as well. > > But is it considered a leak, if the program is going to terminate > right after the function returns? it not a big deal to leak immediately before exit, and a patch whose sole purpose is to plug them is of little value. But if you are already in the vicinity, updating a function that happens to have such a leak, the cost to decide not plugging the leak would be about the same as plugging it, so it would be worth doing in such a case. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html