René Scharfe <l....@web.de> writes: >> "Next call to the function invalidates the return value the last >> caller received" feels like playing with fire. Most existing >> callers are safe in that the first thing they do to the returned >> string is xstrdup() it, but we would need to check all the other >> callers. > > That's the price we pay for using static variables, no? Callers need > to consume them as long as they're fresh and multi-threading is not > allowed.
Yes, I didn't mean to say that fixing this leak by a static whose lifetime rule is "alive until next call" is introducing a new brittleness. The existing callers have lived with that lifetime rule with the callee without the changes in this series, and fixing the leak by replacing _init() with _reset() will make the callee give the same old "alive until next call" lifetime rule to its callers. > Getting a strbuf_add_real_path() in order to avoid static variables > would be nice. And it would also be nice if it worked without calling > chdir(). Nice topics for follow-up patches. :) Yup. Nice, but outside the scope. Of course it is related and can be done as a "while we know about the issue" close follow-up. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
