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  2505 
"Bill Cunningham" <no****@nspam.comwrote 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
On Aug 8, 4:58*pm, "Bill Cunningham" <nos...@nspam.comwrote:
* * 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/c601c3fd60dd536a>.
--
Robert Gamble
Robert Gamble wrote:
On Aug 8, 4:58 pm, "Bill Cunningham" <nos...@nspam.comwrote:
> 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/c601c3fd60dd536a>.
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
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
"Bill Cunningham" <no****@nspam.comwrites:
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) 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"
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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.
"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
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 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_Keith) 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"
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 :-)
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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.
True, but in practice fclose() is likely to call close() or its
equivalent, which is likely to do the right thing.
This was a real problem when NFS first came along: programs didn't
check the result of fclose() (or close(), if they used it directly),
and editors would delete old versions even though writing the new one
had failed.
-- Richard
--
Please remember to mention me / in tapes you leave behind. ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>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.
True, but in practice fclose() is likely to call close() or its
equivalent, which is likely to do the right thing.
Isn't fflush equally likely to do the right thing?
This was a real problem when NFS first came along: programs didn't
check the result of fclose() (or close(), if they used it directly),
and editors would delete old versions even though writing the new one
had failed.
Perhaps, but the conclusion is the same in either case: always check
the result of both fflush and fclose.
--
Keith Thompson (The_Other_Keith) 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"
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>True, but in practice fclose() is likely to call close() or its
equivalent, which is likely to do the right thing.
>Isn't fflush equally likely to do the right thing?
Fflush() is just likely to call write() or equivalent, and check the
result. So it won't see any delayed errors which would be detected
by fclose().
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Robert Gamble <rg*******@gmail.comwrote:
On Aug 8, 4:58=A0pm, "Bill Cunningham" <nos...@nspam.comwrote:
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 ?
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/c601c3fd60dd536a>.
I used to think checking fclose() was unnecessary, but Eric's example
convinced me otherwise; however, do note that it's only true for _write_
streams. I still can't think of an overwhelming reason to check fclose()
for read streams.
Richard rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Robert Gamble <rg*******@gmail.comwrote:
[...]
>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/c601c3fd60dd536a>.
I used to think checking fclose() was unnecessary, but Eric's example
convinced me otherwise; however, do note that it's only true for _write_
streams. I still can't think of an overwhelming reason to check fclose()
for read streams.
Hmm.
I suppose that fclose on a read stream is very unlikely to fail, since
it doesn't do much. But if it *does* fail, it's likely to indicate
some serious problem with the system, something that you might to know
about. Then again, it's likely to be something that's not relevant to
your program, so there's a good chance it can be safely ignored.
--
Keith Thompson (The_Other_Keith) 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"
Keith Thompson <ks***@mib.orgwrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Robert Gamble <rg*******@gmail.comwrote:
[...]
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/c601c3fd60dd536a>.
I used to think checking fclose() was unnecessary, but Eric's example
convinced me otherwise; however, do note that it's only true for _write_
streams. I still can't think of an overwhelming reason to check fclose()
for read streams.
Hmm.
I suppose that fclose on a read stream is very unlikely to fail, since
it doesn't do much. But if it *does* fail, it's likely to indicate
some serious problem with the system, something that you might to know
about. Then again, it's likely to be something that's not relevant to
your program, so there's a good chance it can be safely ignored.
Such problems (and such error messages) are likely to be of interest to
a systems administrator, but not to a normal user. This could be a
reason to check fclose() for read streams only in systems software, not
in (say) a word processor.
Richard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tom Verbeure |
last post by:
Hello All,
so I'm now convinced that unit testing is really the way to go and I
want to add it to an existing project. The first thing that I find
out, is that, well, it's hard work. Harder than...
|
by: lihua |
last post by:
Hi, Group!
I got one question here:
We all know that fclose() must be called after file operations to
avoid unexpected errors.But there are really cases when you forget to
do that!Just
like...
|
by: kathy |
last post by:
if fopen failed, does it necessary to call fclose?
I see an example like this:
....
stream = fopen(...);
if(stream == NULL)
{
....
}
else
|
by: Jon Slaughter |
last post by:
What is the general procedure to optimize hit tests on objects with a mouse
cursor? Just loop through all the objects and check for intersection and
break when found or is there something better?
...
|
by: Rina0 |
last post by:
Cybersecurity engineering is a specialized field that focuses on the design, development, and implementation of systems, processes, and technologies that protect against cyber threats and...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: DJRhino |
last post by:
Private Sub CboDrawingID_BeforeUpdate(Cancel As Integer)
If = 310029923 Or 310030138 Or 310030152 Or 310030346 Or 310030348 Or _
310030356 Or 310030359 Or 310030362 Or...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
| |
