On Sun, Oct 01, 2017 at 04:56:02PM +0200, Martin Ågren wrote: > There is no longer any need to allocate and leak a `struct lock_file`. > Initialize it on the stack instead. > > Instead of setting `lock = NULL` to signal that we have already rolled > back, and that we should not do any more work, check with > `is_lock_file_locked()`. Since we take the lock with > `LOCK_DIE_ON_ERROR`, it evaluates to false exactly when we have called > `rollback_lock_file()`. This looks correct (and is a good direction, as it drops a leak). The original code is actually a bit confusing/unsafe, as we set the "found" flag early and rollback here: > @@ -481,17 +481,15 @@ void add_to_alternates_file(const char *reference) > strbuf_release(&line); > fclose(in); > > - if (found) { > - rollback_lock_file(lock); > - lock = NULL; > - } > + if (found) > + rollback_lock_file(&lock); and that leaves the "out" filehandle dangling. It's correct because of the later "do we still have the lock" check: > - if (lock) { > + if (is_lock_file_locked(&lock)) { > fprintf_or_die(out, "%s\n", reference); but the two spots must remain in sync. If I were writing it from scratch I might have bumped "found" to the scope of the whole function, and then replaced this final "do we still have the lock" with: if (found) rollback_lock_file(&lock); else { fprintf_or_die(out, "%s\n", reference); if (commit_lock_file(&lock)) ...etc... } I don't know if it's worth changing now or not. -Peff