commit_lock_file(): die() if called for unlocked lockfile object

It was previously a bug to call commit_lock_file() with a lock_file
object that was not active (an illegal access would happen within the
function).  It was presumably never done, but this would be an easy
programming error to overlook.  So before continuing, do a consistency
check that the lock_file object really is locked.

Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt
index 99830f3bf3a1d37ff1a2ee8fe19d5e5c4af3f939..65386107594ee41cbeaeae22fdffdd40a2d261e1 100644 (file)
--- a/Documentation/technical/api-lockfile.txt
+++ b/Documentation/technical/api-lockfile.txt
@@ -147,7 +147,8 @@ commit_lock_file::
        `hold_lock_file_for_append`, close the file descriptor and
        rename the lockfile to its final destination. Return 0 upon
        success or a negative value on failure to `close(2)` or
-       `rename(2)`.
+       `rename(2)`. It is a bug to call `commit_lock_file()` for a
+       `lock_file` object that is not currently locked.
 
 rollback_lock_file::
 

diff --git a/lockfile.c b/lockfile.c
index e148227fb16c7e99b7a10e203cdf65f011823dea..c897dd8a9390b508ef23c7afbae46c0c40ae3e6d 100644 (file)
--- a/lockfile.c
+++ b/lockfile.c
@@ -301,6 +301,9 @@ int commit_lock_file(struct lock_file *lk)
 {
        char result_file[PATH_MAX];
 
+       if (!lk->filename[0])
+               die("BUG: attempt to commit unlocked object");
+
        if (close_lock_file(lk))
                return -1;