ferror()

[Stephen Howe]

Hi,

If I attempt to read past the end of a file, feof() will return a non-zero
value. But can I guarantee that ferror() is 0? In short, will the error
indicator be set in some implementations just because the end-of-file
indicator is set? A search on the standard does not reveal if eof is
regarded as an "error" (if does say something, please quote the heading
numbers).

Thanks

Stephen Howe

[Floyd Davidson]

"Stephen Howe" <NO**********@d ial.pipex.com> wrote:

Hi,

If I attempt to read past the end of a file, feof() will return a non-zero
value. But can I guarantee that ferror() is 0? In short, will the error
indicator be set in some implementations just because the end-of-file
indicator is set? A search on the standard does not reveal if eof is
regarded as an "error" (if does say something, please quote the heading
numbers).

There is not much point in using feof(). Whatever function you
use to read data will indicate when an end of file or an i/o
error occurs, for example:

while (fread(..., fp) != 0) {
...
}

When the loop exits, you know positively one or the other
condition has occurred, but generally the the only exception you
want to take is for an error,

if (ferror(fp)) {
... /* handle the error */
}

The program simply continues if no error is indicated, because
the end of file condition is expected.

If an error did occur, it makes no difference if feof() is true
or not.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl***@barrow.co m

[Dan Pop]

In <3f************ **********@read ing.news.pipex. net> "Stephen Howe" <NO**********@d ial.pipex.com> writes:

If I attempt to read past the end of a file, feof() will return a non-zero
value. But can I guarantee that ferror() is 0? In short, will the error
indicator be set in some implementations just because the end-of-file
indicator is set? A search on the standard does not reveal if eof is
regarded as an "error" (if does say something, please quote the heading
numbers).

Having reached the end of file is not considered an error.

OTOH, I can't figure out the practical side of your question. Why do you
need any guarantees about the ferror return value once you have reached
the end of the file?

In practice, reaching the end of file is the most common reason for the
failure of an input function. So, if the input function call returns
a failure indication (EOF or a null pointer), you simply call feof() to
figure out whether it was an eof condition or an I/O error. You don't
need to call ferror() at all in this case.

ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling fclose(),
ferror() returns zero, you can assume that everything was fine up to that
point (if you have performed no actions on that stream that would reset
the stream's error indicator).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[glen herrmannsfeldt]

Dan Pop wrote:

(snip regarding feof() and ferror())

In practice, reaching the end of file is the most common reason for the
failure of an input function. So, if the input function call returns
a failure indication (EOF or a null pointer), you simply call feof() to
figure out whether it was an eof condition or an I/O error. You don't
need to call ferror() at all in this case. ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling fclose(),
ferror() returns zero, you can assume that everything was fine up to that
point (if you have performed no actions on that stream that would reset
the stream's error indicator).

Shouldn't you also check the return value of fclose()?

I believe that in the case of buffering external to C, all the data
won't necessarily be pushed all the way to the disk, and a disk full
condition could still occur.

I do believe that only a small fraction of programs correctly check
the return status on output files.

-- glen

[Stephen Howe]

> OTOH, I can't figure out the practical side of your question. Why do you

need any guarantees about the ferror return value once you have reached
the end of the file?
Colleague's code.

He has a function which calls various combinations of fread(), fgetc(),
fgets() and does not bother to inspect the return values.
At the end, he calls ferror() to see if an error occured reading the file
and returns a value from the function if it was "successful " or "not". I am
wondering what happens if the end-of-file is reached whether ferror()
returns 0 or not. I have to say, it intrinsically does not seem to be
robust. I would be testing every call to fread(), fgetc(), fgets() in case
you have an unexpected truncated file.
ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling fclose(),
ferror() returns zero, you can assume that everything was fine up to that
point (if you have performed no actions on that stream that would reset
the stream's error indicator).

Is that enough? It could be that disk space is tight, ferror() indicates no
error yet calling fclose() flushes any buffers in effect and at that point
the C file system suddenly detects there is a problem. You want to flush
first and then see what ferror() returns or alternatively take note of what
fclose() returns.

Stephen Howe

[those who know me have no need of my name]

in comp.lang.c i read:

Dan Pop wrote:

ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling
fclose(), ferror() returns zero, you can assume that everything was fine
up to that point (if you have performed no actions on that stream that
would reset the stream's error indicator).

Shouldn't you also check the return value of fclose()?

yes, because there may have been buffering of the stream (by default a
stream referencing a file would be block buffered) and the fclose will
flush that data before it closes the underlying interface, and either of
those actions (fflush or underlying_clos e()) may encounter an error.

--
a signature

[Simon Biber]

"glen herrmannsfeldt" <ga*@ugcs.calte ch.edu> wrote:

Shouldn't you also check the return value of fclose()?

I believe that in the case of buffering external to C, all the
data won't necessarily be pushed all the way to the disk, and
a disk full condition could still occur.

I do believe that only a small fraction of programs correctly
check the return status on output files.

If the fclose function returns an error, which could be due to
disk full, is it reasonable to ask the user to rectify that
condition and then retry the fclose?

ie. something like:
while(fclose(fp ))
{
printf("File close failed, press 'r' to retry\n");
if(getchar() != 'r') break;
}

Or is the file pointer invalid after the unsuccessful call?

--
Simon.

[Ben Pfaff]

"Simon Biber" <ne**@ralminNOS PAM.cc> writes:

If the fclose function returns an error, which could be due to
disk full, is it reasonable to ask the user to rectify that
condition and then retry the fclose?

No, you must not do that. See the definition in the Standard:

7.19.5.1 The fclose function
Synopsis
1 #include <stdio.h>
int fclose(FILE *stream);
Description

2 A successful call to the fclose function causes the stream
pointed to by stream to be flushed and the associated file
to be closed. Any unwritten buffered data for the stream are
delivered to the host environment to be written to the file;
any unread buffered data are discarded. Whether or not the
^^^^^^^^^^^^^^^ ^^^
call succeeds, the stream is disassociated from the file and
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^
any buffer set by the setbuf or setvbuf function is
disassociated from the stream (and deallocated if it was
automatically allocated).

--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Dan Pop]

In <GLLBb.15182$8y 1.59614@attbi_s 52> glen herrmannsfeldt <ga*@ugcs.calte ch.edu> writes:

Dan Pop wrote:

(snip regarding feof() and ferror())

In practice, reaching the end of file is the most common reason for the
failure of an input function. So, if the input function call returns
a failure indication (EOF or a null pointer), you simply call feof() to
figure out whether it was an eof condition or an I/O error. You don't
need to call ferror() at all in this case.

ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling fclose(),
ferror() returns zero, you can assume that everything was fine up to that
point (if you have performed no actions on that stream that would reset
the stream's error indicator).

Shouldn't you also check the return value of fclose()?

Have I said or implied otherwise?

Of course you *have* to check it, but this has nothing to do with ferror()
which can no longer be used after the stream has been closed.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[glen herrmannsfeldt]

Dan Pop wrote:
(snip)

ferror() is usually useful for output streams, when you don't want to
bother checking each and every output call. If, before calling fclose(),
ferror() returns zero, you can assume that everything was fine up to that
point (if you have performed no actions on that stream that would reset
the stream's error indicator).

Shouldn't you also check the return value of fclose()?

Have I said or implied otherwise?
Maybe not, but since you didn't mention it, and since the return value
of fclose() is so rarely checked, I thought it was worth adding to
the discussion.
Of course you *have* to check it, but this has nothing to do with ferror()
which can no longer be used after the stream has been closed.

-- glen