Re: [PATCH 3/4] lock_ref_sha1_basic: simplify error code path

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 19, 2014, 02:00 UTC
Message-ID: <20141119020009.GR6527@google.com>
In-Reply-To: <20141119013739.GC2135@peff.net>

Jeff King wrote:

Show 6 quoted lines

> For most errors, we jump to a goto label that unlocks the
> ref and returns NULL. However, in none of these error paths
> would we ever have actually locked the ref. By the time we
> actually take the lock, we follow a different path that does
> not ever hit this goto (we rely on verify_lock to unlock if
> it finds an error).

[...]

>  refs.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)

Wouldn't this leak lock (in all cases) and lock->ref_name and lock->orig_ref_name (on safe_create_leading_directories failure)?