testing fclose...really necessary

[Bill Cunningham]

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

[Malcolm McLean]

"Bill Cunningham" <no****@nspam.c omwrote 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.uk/~bgy1mm

[Robert Gamble]

On Aug 8, 4:58*pm, "Bill Cunningham" <nos...@nspam.c omwrote:

* * 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.c om/group/comp.lang.c/msg/c601c3fd60dd536 a>.

--
Robert Gamble

[Eric Sosman]

Robert Gamble wrote:

On Aug 8, 4:58 pm, "Bill Cunningham" <nos...@nspam.c omwrote:

> 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.c om/group/comp.lang.c/msg/c601c3fd60dd536 a>.

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.

--
Er*********@sun .com

[Default User]

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]

"Bill Cunningham" <no****@nspam.c omwrites:

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_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>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]

"Richard Tobin" <ri*****@cogsci .ed.ac.ukwrote in message
news:g7******** ***@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]

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
es*****@ieee-dot-org.invalid

[Keith Thompson]

ri*****@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_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"