mirrors/nano
1
0
Fork 0
mirror of git://git.sv.gnu.org/nano.git synced 2025-02-21 15:54:19 +03:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Benno Schulenberg 2020-01-31 19:31:55 +01:00
parent 3f5ba950d6
commit 74f4c37d5f
1 changed files with 1 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/files.c
View File

@ -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;