René Scharfe <> 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

> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to