[PATCH v2 1/7] files-backend: prefer "0" for write_in_full() error check
- From
Jeff King <peff@peff.net>
- Date
- Sep 27, 2017, 06:00 UTC
- Message-ID
- <20170927060000.z2bs7lojzh6wprhr@sigill.intra.peff.net>
- In-Reply-To
- <20170927055424.22ati3g24xaqtqrk@sigill.intra.peff.net>
Commit 06f46f237a (avoid "write_in_full(fd, buf, len) != len" pattern, 2017-09-13) converted this callsite from:
write_in_full(...) != 1
to
write_in_full(...) < 0
But during the conflict resolution in c50424a6f0 (Merge branch 'jk/write-in-full-fix', 2017-09-25), this morphed into
write_in_full(...) < 1
This behaves as we want, but we prefer to avoid modeling the "less than length" error-check which can be subtly buggy, as shown in efacf609c8 (config: avoid "write_in_full(fd, buf, len) < len" pattern, 2017-09-13).
Signed-off-by: Jeff King <peff@peff.net> --- refs/files-backend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c index dac33628b3..e35c64c001 100644 --- a/refs/files-backend.c +++ b/refs/files-backend.c @@ -3007,7 +3007,7 @@ static int files_reflog_expire(struct ref_store *ref_store, } else if (update && (write_in_full(get_lock_file_fd(&lock->lk), oid_to_hex(&cb.last_kept_oid), GIT_SHA1_HEXSZ) < 0 || - write_str_in_full(get_lock_file_fd(&lock->lk), "\n") < 1 || + write_str_in_full(get_lock_file_fd(&lock->lk), "\n") < 0 || close_ref_gently(lock) < 0)) { status |= error("couldn't write %s", get_lock_file_path(&lock->lk));
-- 2.14.2.988.g01c8b37dde