Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

write_history silently eats IO errors in fprintf rather than failing #66

Open
lf- opened this issue May 22, 2024 · 2 comments
Open

write_history silently eats IO errors in fprintf rather than failing #66

lf- opened this issue May 22, 2024 · 2 comments

Comments

@lf-
Copy link

lf- commented May 22, 2024

editline/src/editline.c

Lines 1619 to 1634 in c50d4c3

int write_history(const char *filename)
{
FILE *fp;
int i = 0;
hist_alloc();
fp = fopen(filename, "w");
if (!fp)
return EOF;
while (i < H.Size)
fprintf(fp, "%s\n", H.Lines[i++]);
return fclose(fp);
}

Note that fprintf has no check on its return value so it could fail without being reported. I am unsure if the IO errors turn the FILE * into some poison that would cause the fclose() to fail, but somehow I suspect they would not.

@lf-
Copy link
Author

lf- commented May 22, 2024

Also, the errno handling here completely violates the semantics of how readline does it: the return value should be 0 on success or errno on failure, and EOF is not a valid errno value. GNU readline by comparison does not guarantee that errno the global variable will not be clobbered on return, so the only way of getting its errno out is to look at the return value, but editline return value here is not always a valid errno.

The fix for that is to stop returning EOF and return errno there instead.

@troglobit
Copy link
Owner

The editline library is not intended to be a drop-in replacement for GNU readline. That being said, it's always a good idea to follow the principle of least surprise.

Pull requests are welcome that improve the stability and usability of the library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants