From 74f4c37d5f3547d476b54582d1d95ee109907c01 Mon Sep 17 00:00:00 2001 From: Benno Schulenberg Date: Fri, 31 Jan 2020 19:31:55 +0100 Subject: [PATCH] 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. --- src/files.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/src/files.c b/src/files.c index 987164c2..dab30f28 100644 --- 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;