Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > ferror()

Reply
Thread Tools

ferror()

 
 
Stephen Howe
Guest
Posts: n/a
 
      12-10-2003
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





 
Reply With Quote
 
 
 
 
Floyd Davidson
Guest
Posts: n/a
 
      12-10-2003
"Stephen Howe" <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      12-10-2003
In <3fd7370c$0$9391$(E-Mail Removed) > "Stephen Howe" <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      12-10-2003
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

 
Reply With Quote
 
Simon Biber
Guest
Posts: n/a
 
      12-11-2003
"glen herrmannsfeldt" <(E-Mail Removed)> 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.


 
Reply With Quote
 
Stephen Howe
Guest
Posts: n/a
 
      12-11-2003
> 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


 
Reply With Quote
 
those who know me have no need of my name
Guest
Posts: n/a
 
      12-11-2003
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_close()) may encounter an error.

--
a signature
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      12-11-2003
"Simon Biber" <(E-Mail Removed)> 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[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      12-11-2003
In <GLLBb.15182$8y1.59614@attbi_s52> glen herrmannsfeldt <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      12-11-2003
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments