10 Jun
2016
10 Jun
'16
7:01 a.m.
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?