[PATCH] Fix return value of fwrite when a 'hard' error occurs
When a 'hard' error occurs, fwrite reports that all data was written or buffered even if that is not the case. It should report how much data was actually written and buffered. Signed-off-by: Jan Vangorp <jan.vangorp_ext@softathome.com> --- libc/stdio/_WRITE.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libc/stdio/_WRITE.c b/libc/stdio/_WRITE.c index 113f0eb..f95bd1b 100644 --- a/libc/stdio/_WRITE.c +++ b/libc/stdio/_WRITE.c @@ -76,6 +76,7 @@ size_t attribute_hidden __stdio_WRITE(register FILE *stream, */ if (errno != EINTR && errno != EAGAIN) { /* do we have other "soft" errors? */ + bufsize -= todo; break; } #ifdef __STDIO_BUFFERS -- 1.9.1
Hi Jan, Jan Vangorp wrote,
When a 'hard' error occurs, fwrite reports that all data was written or buffered even if that is not the case. It should report how much data was actually written and buffered.
Thank you very much for both patches. Can you give us a short background information what is the motivation of this patches? Do you have some applications failing without these patches or do you want to make uClibc-ng more standard compliant? Best regards Waldemar
Hi Waldemar, Waldemar Brodkorb wrote,
Hi Jan, Jan Vangorp wrote,
When a 'hard' error occurs, fwrite reports that all data was written or buffered even if that is not the case. It should report how much data was actually written and buffered.
Thank you very much for both patches. Can you give us a short background information what is the motivation of this patches? Do you have some applications failing without these patches or do you want to make uClibc-ng more standard compliant?
We have software that for some projects needs to be compiled against uClibc and against glibc for others. So you could say we want uClibc-ng to be more standard compliant. We detected the different behaviour between uClibc and glib when retuning -1 on fopencookie write error caused a crash when using glibc and an infinite loop when using uClibc and returning 0. The underlying file descriptor in our case is a socket causing an EPIPE error when the remote end closed the connection. For now we solve this particular instance with a compile time switch but are unsure about other places in the codebase where we might have the same problem but have not noticed it yet. So we would like to have the root cause solved. The faulty return value of fwrite on 'hard' errors is something I noticed when testing the fopencookie patch on a small test program. Best regards, Jan
Hi Jan, Jan Vangorp wrote,
When a 'hard' error occurs, fwrite reports that all data was written or buffered even if that is not the case. It should report how much data was actually written and buffered.
Signed-off-by: Jan Vangorp <jan.vangorp_ext@softathome.com>
Thanks, committed and pushed, Waldemar
participants (2)
-
Jan Vangorp -
Waldemar Brodkorb