diff options
| author | Martin Ågren <martin.agren@gmail.com> | 2018-05-09 20:55:38 (GMT) |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2018-05-10 05:54:45 (GMT) |
| commit | b227586831ed393e1d60629bfedcef01be4b9c22 (patch) | |
| tree | c58f4d54e1818bf4969d77840f47e893cee7b4de /fast-import.c | |
| parent | 3c6fad4a3fcc9a01dd3d9678360907271ad85920 (diff) | |
| download | git-b227586831ed393e1d60629bfedcef01be4b9c22.zip git-b227586831ed393e1d60629bfedcef01be4b9c22.tar.gz git-b227586831ed393e1d60629bfedcef01be4b9c22.tar.bz2 | |
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>
Diffstat (limited to 'fast-import.c')
| -rw-r--r-- | fast-import.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/fast-import.c b/fast-import.c index b5db5d2..2bce22a 100644 --- a/fast-import.c +++ b/fast-import.c @@ -1858,7 +1858,7 @@ static void dump_marks_helper(FILE *f, static void dump_marks(void) { - static struct lock_file mark_lock; + struct lock_file mark_lock = LOCK_INIT; FILE *f; if (!export_marks_file || (import_marks_file && !import_marks_file_done)) |