Re: testing fclose...really necessary

"Bill Cunningham" <nospam@xxxxxxxxx> 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@xxxxxxx <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"
.

Relevant Pages

  • Convention for C functions success/failure
    ... What is the convention for writing C functions which don't return a ... value, but can fail? ... PyArg_ParseTuple returns 0 on failure and 1 on success. ...
    (comp.lang.python)
  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... the correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.math)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.crypt)