[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

testing fclose...really necessary

Bill Cunningham

8/8/2008 8:58:00 PM

Is it really necessary to check the return type (int) or fclose ? fopen
I can understand but what about using

fflsuh(fp); /* fopen's pointer */
fclose(fp);

Would that take care of any unforseen truncation ?

Bill
16 Answers

Malcolm McLean

8/8/2008 9:49:00 PM

0


"Bill Cunningham" <nospam@nspam.com> wrote in message
> Is it really necessary to check the return type (int) or fclose ? fopen
> I can understand but what about using
>
> fflsuh(fp); /* fopen's pointer */
> fclose(fp);
>
> Would that take care of any unforseen truncation ?
>
If the program won't close a file successfully that means that something is
seriously wrong with the computer. Like the disk being full up, or the
device driver corruupted. At the very least the FILE * you pass to the
function moght have been corrupted.
The important thing is to tell the user, if the data is important, what has
happened.
However a lot of programs don't save important data. Then it is arguably an
acceptable laziness not to check fclose(). The program is unlikely to be
able to do anything about it without an unacceptable level of extra
programming, and errors are very rare.
fflush() would have to be checked instead of fclose(), so you don't really
save anything with your suggested strategy.

--
Free games and programming goodies.
http://www.personal.leeds.ac....

tigervamp

8/8/2008 9:53:00 PM

0

On Aug 8, 4:58 pm, "Bill Cunningham" <nos...@nspam.com> wrote:
>     Is it really necessary to check the return type (int) or fclose ? fopen
> I can understand but what about using
>
> fflsuh(fp); /* fopen's pointer */
> fclose(fp);
>
> Would that take care of any unforseen truncation ?
>
> Bill

Eric Sosman posted a compelling example of what can go wrong when you
don't check the return value of fclose() a while back, you can read it
at <http://groups.google.com/group/comp.lang.c/msg/c601c3fd60....

--
Robert Gamble

Eric Sosman

8/8/2008 10:02:00 PM

0

Robert Gamble wrote:
> On Aug 8, 4:58 pm, "Bill Cunningham" <nos...@nspam.com> wrote:
>> Is it really necessary to check the return type (int) or fclose ? fopen
>> I can understand but what about using
>>
>> fflsuh(fp); /* fopen's pointer */
>> fclose(fp);
>>
>> Would that take care of any unforseen truncation ?
>>
>> Bill
>
> Eric Sosman posted a compelling example of what can go wrong when you
> don't check the return value of fclose() a while back, you can read it
> at <http://groups.google.com/group/comp.lang.c/msg/c601c3fd60....

Gad, that was an awful experience! I wound up flying to St. Louis
to try to placate the irate customer by allowing him to rip my face
off with a cheese grater -- well, perhaps I exaggerate, but my day in
St. Louis remains in memory as one of the most unpleasant of my working
life.

The thoroughness of the error-checking should be a function of the
importance of the data, not of the programmer's ideas of convenience.

--
Eric.Sosman@sun.com

Default User

8/8/2008 10:34:00 PM

0

Eric Sosman wrote:


> Gad, that was an awful experience! I wound up flying to St. Louis
> to try to placate the irate customer by allowing him to rip my face
> off with a cheese grater -- well, perhaps I exaggerate, but my day in
> St. Louis remains in memory as one of the most unpleasant of my
> working life.


My fair city now tarnished in your memory. Like getting sick after
eating some food at a kid.




Brian

Keith Thompson

8/8/2008 10:39:00 PM

0

"Bill Cunningham" <nospam@nspam.com> writes:
> Is it really necessary to check the return type (int) or fclose ? fopen
> I can understand but what about using
>
> fflsuh(fp); /* fopen's pointer */

Typo: fflush(fp);

> fclose(fp);
>
> Would that take care of any unforseen truncation ?

No. fflush can fail as easily as fclose can; you should check the
result of both calls (though it's common not to bother checking the
result of fflush(stdout)).

If you've been writing to a stream (fp, stdout, whatever), it can have
buffered data that hasn't yet been written to the physical file (your
screen, foo.dat, whatever). Either flushing or closing the stream
will cause the system to *attempt* to write out any buffered data, or
at least to pass it on to another part of the system that will
eventually write it to the physical media. In either case, that can
fail for any number of reasons: the disk might be full, you might have
unplugged something, etc.

When writing to stdout or stderr, it's fairly common to omit checks,
since (a) any failure will often be fairly obvious to the user, and
(b) there's not much you can do to recover (where do you write the
error message?). For anything else, you should always check the
result of every I/O operation, even if all you do in the event of
failure is to abort the program with an error message.

(*Sometimes* it might be better to atttempt to continue running after
an error, but you're not writing anything where that would apply.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

richard

8/8/2008 11:48:00 PM

0

In article <ln4p5v169w.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:

>If you've been writing to a stream (fp, stdout, whatever), it can have
>buffered data that hasn't yet been written to the physical file (your
>screen, foo.dat, whatever). Either flushing or closing the stream
>will cause the system to *attempt* to write out any buffered data, or
>at least to pass it on to another part of the system that will
>eventually write it to the physical media. In either case, that can
>fail for any number of reasons: the disk might be full, you might have
>unplugged something, etc.

fflush() may well succeed even though the data has not yet reached its
destination. fclose() on the other hand should not return until
the lower levels have reported success. Write failures can be caused
by common things like full filesystems, and the failure may not be
immediate for a networked fileserver.

>When writing to stdout or stderr, it's fairly common to omit checks,
>since (a) any failure will often be fairly obvious to the user, and
>(b) there's not much you can do to recover (where do you write the
>error message?).

You may not be able to recover, but you can avoid taking some
destructive action like deleting the input file.

>For anything else, you should always check the
>result of every I/O operation, even if all you do in the event of
>failure is to abort the program with an error message.

Or check ferror() at the end of a loop, if it's tedious to check every
operation. But don't do this for infinite, or even very lengthy,
loops.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Bill Cunningham

8/9/2008 12:32:00 AM

0


"Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message
news:g7im03$2jhv$1@pc-news.cogsci.ed.ac.uk...

> fflush() may well succeed even though the data has not yet reached its
> destination. fclose() on the other hand should not return until
> the lower levels have reported success. Write failures can be caused
> by common things like full filesystems, and the failure may not be
> immediate for a networked fileserver.
>
>>When writing to stdout or stderr, it's fairly common to omit checks,
>>since (a) any failure will often be fairly obvious to the user, and
>>(b) there's not much you can do to recover (where do you write the
>>error message?).

I see.

Bill

Eric Sosman

8/9/2008 1:37:00 AM

0

Default User wrote:
> Eric Sosman wrote:
>
>
>> Gad, that was an awful experience! I wound up flying to St. Louis
>> to try to placate the irate customer by allowing him to rip my face
>> off with a cheese grater -- well, perhaps I exaggerate, but my day in
>> St. Louis remains in memory as one of the most unpleasant of my
>> working life.
>
>
> My fair city now tarnished in your memory. Like getting sick after
> eating some food at a kid.

<off-topic>

No doubt your city is fair, but all I got to see of it
was the airport and the wrong end of a cheese grater ...
Keep in mind that the fault was not your city's, but ours
for failing to check for a successful fclose(). Your fair
city was only an innocent bystander, wounded in the confusion.
(That's the most painful spot to be wounded ...)

</off-topic>


--
Eric Sosman
esosman@ieee-dot-org.invalid

Keith Thompson

8/9/2008 1:39:00 AM

0

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
[...]
> fflush() may well succeed even though the data has not yet reached its
> destination. fclose() on the other hand should not return until
> the lower levels have reported success. Write failures can be caused
> by common things like full filesystems, and the failure may not be
> immediate for a networked fileserver.

That's not guaranteed, and it may not always be possible. In fact,
the standard uses the same wording for both fclose and fflush.

C99 7.19.5.1 (fclose):

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.

C99 7.19.5.2 (fflush):

If stream points to an output stream or an update stream in which
the most recent operation was not input, the fflush function
causes any unwritten data for that stream to be delivered to the
host environment to be written to the file; otherwise, the
behavior is undefined.

>>When writing to stdout or stderr, it's fairly common to omit checks,
>>since (a) any failure will often be fairly obvious to the user, and
>>(b) there's not much you can do to recover (where do you write the
>>error message?).
>
> You may not be able to recover, but you can avoid taking some
> destructive action like deleting the input file.

Ideally, yes.

What I should have said is that such checks are often omitted for
programs where stdout and stderr are normally expected to be written
to an interactive device.

>>For anything else, you should always check the
>>result of every I/O operation, even if all you do in the event of
>>failure is to abort the program with an error message.
>
> Or check ferror() at the end of a loop, if it's tedious to check every
> operation. But don't do this for infinite, or even very lengthy,
> loops.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

gordon

8/9/2008 4:00:00 AM

0

In error-retentive programming, it is very important to check every
kind of write, fflush(), and fclose() for errors (including those
on stderr), and to report the failure to write the data on stderr,
with a description of the error (e.g. from perror()) and the data
that you failed to write. If that fails, report THAT error also
(infinite recursion here) on stderr.

This way, if you get a full disk, the disk will stay filled up with
error messages even if the administrator frees up some space :-)