lock_file: make function-local locks non-static
Placing `struct lock_file`s on the stack used to be a bad idea, because
the temp- and lockfile-machinery would keep a pointer into the struct.
But after 076aa2cbd
(tempfile: auto-allocate tempfiles on heap,
2017-09-05), we can safely have lockfiles on the stack. (This applies
even if a user returns early, leaving a locked lock behind.)
These `struct lock_file`s are local to their respective functions and we
can drop their staticness.
For good measure, I have inspected these sites and come to believe that
they always release the lock, with the possible exception of bailing out
using `die()` or `exit()` or by returning from a `cmd_foo()`.
As pointed out by Jeff King, it would be bad if someone held on to a
`struct lock_file *` for some reason. After some grepping, I agree with
his findings: no-one appears to be doing that.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:

committed by
Junio C Hamano

parent
3c6fad4a3f
commit
b227586831
@ -2989,7 +2989,7 @@ static int files_reflog_expire(struct ref_store *ref_store,
|
||||
{
|
||||
struct files_ref_store *refs =
|
||||
files_downcast(ref_store, REF_STORE_WRITE, "reflog_expire");
|
||||
static struct lock_file reflog_lock;
|
||||
struct lock_file reflog_lock = LOCK_INIT;
|
||||
struct expire_reflog_cb cb;
|
||||
struct ref_lock *lock;
|
||||
struct strbuf log_file_sb = STRBUF_INIT;
|
||||
|
Reference in New Issue
Block a user