This is the mail archive of the
mailing list for the Cygwin project.
RE: short fread(), but no ferror/feof
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Fri, 10 Dec 2004 13:46:22 -0000
- Subject: RE: short fread(), but no ferror/feof
> -----Original Message-----
> From: cygwin-owner On Behalf Of Jason Tishler
> Sent: 10 December 2004 12:15
> On Fri, Dec 10, 2004 at 11:18:12AM +0100, Peter Astrand wrote:
> > However, since my example code
> > (http://cygwin.com/ml/cygwin/2004-12/msg00305.html) still fails,
> > something is still wrong. Is it possible the the "fix"
> above actually
> > caused this problem?
> AFAICT, the problems indicate by the following:
> were already there before I submitted my unbuffered fread() newlib
The fix and the problem Peter is seeing are orthogonal.
The fix referred to above fixes this problem:
"Hence, one can see that fread() in unbuffered mode always returns the
specified count instead of the number of elements actually read."
That is why, as Peter has observed, fread() returns the number of elements
actually read. Without the patch, it would have been returning the entire
number requested, which would have been even wronger.
However Peter's problem is that when fread() does a partial read, it doesn't
set either the EOF mark or the error indication on the file stream. A strict
reading of the fread() specification suggests that it should have set one of
those. OTOH, there isn't actually any error or EOF here. It could possibly be
argued from the specified behaviour of read() and pipes that the error mark
should be set and that errno should be EAGAIN. It may well be in practice that
errno does indeed have the value EAGAIN but fread() can't return -1 because
otherwise the application wouldn't know how much data it _had_ read.
Of course, Peter can always detect when this situation has occurred, precisely
because fread() returns a value that, while >= 0, is < the number of elements
requested, and when feof() and ferror() both return zero, his code could deduce
that it's a short read from a pipe and try again.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html