Re: [PATCH v3 10/13] rerere.c: move error_errno() closer to the source system call
From: Stefan Beller <hidden>
Date: 2017-05-30 18:58:41
On Thu, May 25, 2017 at 8:35 PM, Junio C Hamano [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From: Nguyễn Thái Ngọc Duy <redacted> We are supposed to report errno from fopen(). fclose() between fopen() and the report function could either change errno or reset it. Signed-off-by: Junio C Hamano <redacted> --- rerere.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)diff --git a/rerere.c b/rerere.c index 1351b0c3fb..c26c29f87a 100644 --- a/rerere.c +++ b/rerere.c@@ -489,8 +489,9 @@ static int handle_file(const char *path, unsigned char *sha1, const char *output if (output) { io.io.output = fopen(output, "w"); if (!io.io.output) { + error_errno("Could not write %s", output); fclose(io.input); - return error_errno("Could not write %s", output); + return -1;
and here we assume fclose doesn't error out.
This is ok as we are sure it cannot be EBADF as we just opened that
fd and as we did not read from io.input yet, any errno from close(2), fflush(3)
are not expected?
close(2) may yield an EINTR, in which case we may want to
while (fclose(io.input) && errno != EINTR)
; /*do nothing*/
On the other hand this is already in the error path, so maybe we're ok
leaking an fd here in case of a signal?