summaryrefslogtreecommitdiff
path: root/tempfile.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2017-09-05 12:14:26 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-09-06 08:19:53 (GMT)
commit45c6b1ed24724f7f3041a60a4313df7d9c4b9909 (patch)
tree57ba55efa89a67abe3c54ca3c11a7c50af93662e /tempfile.c
parentd88ef6605120fd75be38376ba147623cf427bf73 (diff)
downloadgit-45c6b1ed24724f7f3041a60a4313df7d9c4b9909.zip
git-45c6b1ed24724f7f3041a60a4313df7d9c4b9909.tar.gz
git-45c6b1ed24724f7f3041a60a4313df7d9c4b9909.tar.bz2
always check return value of close_tempfile
If close_tempfile() encounters an error, then it deletes the tempfile and resets the "struct tempfile". But many code paths ignore the return value and continue to use the tempfile. Instead, we should generally treat this the same as a write() error. Note that in the postimage of some of these cases our error message will be bogus after a failed close because we look at tempfile->filename (either directly or via get_tempfile_path). But after the failed close resets the tempfile object, this is guaranteed to be the empty string. That will be addressed in a future patch (because there are many more cases of the same problem than just these instances). Note also in the hunk in gpg-interface.c that it's fine to call delete_tempfile() in the error path, even if close_tempfile() failed and already deleted the file. The tempfile code is smart enough to know the second deletion is a noop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'tempfile.c')
0 files changed, 0 insertions, 0 deletions