nano

commit 74f4c37d5f3547d476b54582d1d95ee109907c01
parent 3f5ba950d6b746085e1182424372c60f3b7cc1b3
Author: Benno Schulenberg <bensberg@telfort.nl>
Date:   Fri, 31 Jan 2020 19:31:55 +0100

locking: avoid crashing when there is a problem writing the lock file

The call of ferror() as parameter of a %s specifier was a mistake --
it returns a number, not a string.  Avoid the problem by combining
two error checks.

The man page of fwrite() does not say anything about errno, but I guess
that the function calls write() and that the possible error numbers of
that function apply.

In theory it is now possible that fclose() fails and returns an error
that then masks an earlier error of fwrite().  But I can't be bothered:
lock files are not essential, and any errors that might occur are most
likely overlooked anyway because they are not displayed in red.

This fixes https://savannah.gnu.org/bugs/?57724.

Bug existed since lock files were introduced, in version 2.3.2,
commit bf88d27a.

Diffstat:
M
src/files.c
 | 
9
+--------

1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/files.c b/src/files.c
@@ -246,14 +246,7 @@ int write_lockfile(const char *lockfilename, const char *origfilename, bool modi
 
 	wroteamt = fwrite(lockdata, sizeof(char), LOCKSIZE, filestream);
 
-	if (wroteamt < LOCKSIZE) {
-		statusline(MILD, _("Error writing lock file %s: %s"),
-							lockfilename, ferror(filestream));
-		fclose(filestream);
-		goto free_the_data;
-	}
-
-	if (fclose(filestream) == EOF) {
+	if (fclose(filestream) == EOF || wroteamt < LOCKSIZE) {
 		statusline(MILD, _("Error writing lock file %s: %s"),
 							lockfilename, strerror(errno));
 		goto free_the_data;