8 Jun
2016
8 Jun
'16
10 p.m.
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(a)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
9 Jun
9 Jun
9:21 p.m.
New subject: [PATCH] Fix return value of fwrite when a 'hard' error occurs
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
10 Jun
10 Jun
7:01 a.m.
New subject: [PATCH] Fix return value of fwrite when a 'hard' error occurs
Hi Waldemar,
Waldemar Brodkorb wrote,
Hi Jan,
Jan Vangorp wrote,
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
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?
13 Jun
13 Jun
8:41 p.m.
New subject: [PATCH] Fix return value of fwrite when a 'hard' error occurs
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(a)softathome.com>
Thanks,
committed and pushed,
Waldemar
2885
days inactive
2890
days old
3 comments
2 participants
participants (2)
-
Jan Vangorp -
Waldemar Brodkorb