git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

From
Jeff King <peff@peff.net>
Date
Feb 17, 2017, 21:07 UTC
Message-ID
<20170217210749.6dqmaotleefid76y@sigill.intra.peff.net>
In-Reply-To
<20170217205442.wnldfsxbj3dnnqvj@sigill.intra.peff.net>
On Fri, Feb 17, 2017 at 03:54:42PM -0500, Jeff King wrote:
> I guess we are simultaneously assuming that it is OK to munge errno on
> success in our function, but that fclose() will not do so. Which seems a
> bit hypocritical. Maybe the "if" dance is better.
So here's that patch with a justification.

At this point, this snippet of code would be appropriate to pull into xfclose() if we wanted. But possibly that is the wrong direction, as it encourages callers to do:

  if (xfclose(fp))
	err = error_errno("failure writing to ...");
when they could do:
  if (ferror(fp))
	err = error("failure writing to ...");
  if (fclose(fp))
        err = error_errno("failure writing to ...");

While longer, it's arguably better for them to distinguish the two cases. It's only worth doing the errno magic when the close is deep inside a callstack, and passing out the two cases is awkward.

-- >8 --
Subject: tempfile: set errno to a known value before calling ferror()

In close_tempfile(), we return an error if ferror() indicated a previous failure, or if fclose() failed. In the latter case, errno is set and it is useful for callers to report it.

However, if _only_ ferror() triggers, then the value of errno is based on whatever syscall happened to last fail, which may not be related to our filehandle at all. A caller cannot tell the difference between the two cases, and may use "die_errno()" or similar to report a nonsense errno value.

One solution would be to actually pass back separate return values for the two cases, so a caller can write a more appropriate message for each case. But that makes the interface clunky.

Instead, let's just set errno to the generic EIO in this case. That's not as descriptive as we'd like, but at least it's predictable. So it's better than the status quo in all cases but one: when the last syscall really did involve a failure on our filehandle, we'll be wiping that out. But that's a fragile thing for us to rely on.

In any case, we'll let the errno result from fclose() take precedence over our value, as we know that's recent and accurate (and many I/O errors will persist through the fclose anyway).

Signed-off-by: Jeff King <peff@peff.net>
---
 tempfile.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tempfile.c b/tempfile.c
index ffcc27237..684371067 100644
--- a/tempfile.c
+++ b/tempfile.c
@@ -247,8 +247,13 @@ int close_tempfile(struct tempfile *tempfile)
 	tempfile->fd = -1;
 	if (fp) {
 		tempfile->fp = NULL;
-		err = ferror(fp);
-		err |= fclose(fp);
+		if (ferror(fp)) {
+			err = -1;
+			if (!fclose(fp))
+				errno = EIO;
+		} else {
+			err = fclose(fp);
+		}
 	} else {
 		err = close(fd);
 	}
-- 
2.12.0.rc1.612.ga5f664feb
Previous: Jeff KingNext: Junio C Hamano
Message 16 of 24 in “Confusing git messages when disk is full.”
  1. Jáchym BarvínekFeb 12, 2017
  2. Jeff KingFeb 15, 2017
  3. Junio C HamanoFeb 15, 2017
  4. Jeff KingFeb 15, 2017
  5. Junio C HamanoFeb 15, 2017
  6. Jeff KingFeb 15, 2017
  7. Junio C HamanoFeb 15, 2017
  8. Jeff KingFeb 15, 2017
  9. Andreas SchwabFeb 16, 2017
  10. Jeff KingFeb 16, 2017
  11. tempfile: avoid "ferror | fclose" trickJeff King, Feb 16, 2017
  12. Michael HaggertyFeb 17, 2017
  13. Jeff KingFeb 17, 2017
  14. Michael HaggertyFeb 17, 2017
  15. Jeff KingFeb 17, 2017
  16. Jeff KingFeb 17, 2017
  17. Junio C HamanoFeb 17, 2017
  18. Jeff KingFeb 17, 2017
  19. Junio C HamanoFeb 17, 2017
  20. Jeff KingFeb 17, 2017
  21. Junio C HamanoFeb 17, 2017
  22. Jeff KingFeb 17, 2017
  23. Junio C HamanoFeb 17, 2017
  24. Jeff KingFeb 17, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.