By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,140 Members | 1,277 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,140 IT Pros & Developers. It's quick & easy.

fopen and fclose?

P: n/a
if fopen failed, does it necessary to call fclose?

I see an example like this:
....
stream = fopen(...);
if(stream == NULL)
{
....
}
else
{
....
}
fclose(stream);
....

By my understanding, it should like this:
....
stream = fopen(...);
if(stream == NULL)
{
....
}
else
{
....
fclose(stream);
}

Feb 3 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
It should be like this:

stream = fopen(...);
if (stream == NULL)
{
...
}
else
{
...
fclose(stream);
}

fclose'ing a NULL pointer is undefined and could cause problems.
fclose a stream ONLY iff it is a valid open stream.

Feb 3 '06 #2

P: n/a
kathy wrote:
if fopen failed, does it necessary to call fclose?
It doesn't hurt anything to call fclose with a null pointer, and the
function will return an error code if it fails to close the supplied
file.

I see an example like this:
...
stream = fopen(...);
if(stream == NULL)
{
...
}
else
{
...
}
fclose(stream);
...

By my understanding, it should like this:
...
stream = fopen(...);
if(stream == NULL)
{
...
}
else
{
...
fclose(stream);
}


Your way is preferable, IMHO, but I think either is legal. Better still
might be to use std::fstream instead. :-)

Cheers! --M

Feb 3 '06 #3

P: n/a
kathy wrote:
if fopen failed, does it necessary to call fclose?
No. And actually I can't find any description of what's going to happen
if you pass a null pointer to 'fclose'. Conclusion: it's undefined
behaviour and should be avoided. IOW, you must _not_ call 'fclose' for
a pointer obtained from 'fopen' if opening failed (and null pointer is
returned).
[..]


V
Feb 3 '06 #4

P: n/a
mlimber wrote:
kathy wrote:
if fopen failed, does it necessary to call fclose?


It doesn't hurt anything to call fclose with a null pointer


I stand corrected.

Feb 3 '06 #5

P: n/a
mlimber wrote:
mlimber wrote:
kathy wrote:
if fopen failed, does it necessary to call fclose?


It doesn't hurt anything to call fclose with a null pointer


I stand corrected.


Hmm. On second... er, third thought, I'm not sure what the standard
mandates, but the IRIX 6.5 manpages do say: "For fclose, EOF is
returned if stream is NULL, or stream is not active, or there was an
error when flushing buffered writes, or there was an error closing the
underlying file descriptor."

Cheers! --M

Feb 3 '06 #6

P: n/a
mlimber wrote:

Hmm. On second... er, third thought, I'm not sure what the standard
mandates, but the IRIX 6.5 manpages do say: "For fclose, EOF is
returned if stream is NULL, or stream is not active, or there was an
error when flushing buffered writes, or there was an error closing the
underlying file descriptor."


IRIX man pages are not the Standard. There's no similar wording in
either the C or C++ standards.

Here's the wording from the C99 draft standard:

7.19.5.1 The fclose function

Synopsis

[#1]

#include <stdio.h>
int fclose(FILE *stream);

Description

[#2] 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. The stream is disassociated
from the file. If the associated buffer was automatically
allocated, it is deallocated.

Returns

[#3] The fclose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.

Brian
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Feb 4 '06 #7

P: n/a
Default User <de***********@yahoo.com> wrote:
7.19.5.1 The fclose function Returns

[#3] The fclose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.


Out of interest, could one not assume that "any error" will include
having passed 0 to fclose .. ?

regards
--
jb

(reply address in rot13, unscramble first)
Feb 4 '06 #8

P: n/a
Jakob Bieling wrote:
Default User <de***********@yahoo.com> wrote:
7.19.5.1 The fclose function

Returns

[#3] The fclose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.


Out of interest, could one not assume that "any error" will include
having passed 0 to fclose .. ?


Do you have some sort of support for that?

I think the fact that it differs from the implementation-specific man
page should tell you what you need to know.

Closing a null FILE* is UB.
Brian
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Feb 4 '06 #9

P: n/a
On 3 Feb 2006 12:05:06 -0800, "kathy" <yq*****@yahoo.com> wrote:
if fopen failed, does it necessary to call fclose?

I see an example like this:
...
stream = fopen(...);
if(stream == NULL)
{
...
}
else
{
...
}
fclose(stream);
...

By my understanding, it should like this:
...
stream = fopen(...);
if(stream == NULL)
{
...
}
else
{
...
fclose(stream);
}

else {
....
if (fclose(stream) == 0) {
// success
} else {
// error
}
}

Best wishes,
Roland Pibinger
Feb 4 '06 #10

P: n/a
Default User <de***********@yahoo.com> wrote:
Jakob Bieling wrote:
Default User <de***********@yahoo.com> wrote:
7.19.5.1 The fclose function
Returns

[#3] The fclose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.


Out of interest, could one not assume that "any error" will include
having passed 0 to fclose .. ?


Do you have some sort of support for that?


The only support is that paragraph you cited, since I do not call
fclose with a 0-pointer either (nor would I encourage anyone to do so).

Guess I am just complaining about them writing "any error", when in
fact passing a 0-pointer is not covered.
I think the fact that it differs from the implementation-specific man
page should tell you what you need to know.

Agreed.

regards
--
jb

(reply address in rot13, unscramble first)
Feb 4 '06 #11

P: n/a
Jakob Bieling wrote:

Guess I am just complaining about them writing "any error", when in
fact passing a 0-pointer is not covered.

Many functions, especially those inherited from C, accept null pointers
without defined behavior. Notably most of the C-style string functions.

Brian

Feb 5 '06 #12

P: n/a
Default User wrote:
Jakob Bieling wrote:

Guess I am just complaining about them writing "any error", when in
fact passing a 0-pointer is not covered.

Many functions, especially those inherited from C, accept null pointers
without defined behavior. Notably most of the C-style string functions.

Absolutely, completely wrong.

7.1.4 of the C standard says that:

If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer outside the address
space of the program, OR A NULL POINTER, or a pointer to on-modifiable
storage when the corresponding parameter is not const-qualified) or a
type (after promotion) not expected by a function with variable number
of arguments, the behavior is undefined.

The string functions as does fclose, do not specify behavior for
being passed null behavior, hence by 7.1.4 the behavior is undefined.
Feb 14 '06 #13

P: n/a
Ron Natalie wrote:
Default User wrote:
Jakob Bieling wrote:

Guess I am just complaining about them writing "any error", when in
fact passing a 0-pointer is not covered.

Many functions, especially those inherited from C, accept null pointers
without defined behavior. Notably most of the C-style string functions.

Absolutely, completely wrong.

7.1.4 of the C standard says that:

If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer outside the address
space of the program, OR A NULL POINTER, or a pointer to on-modifiable
storage when the corresponding parameter is not const-qualified) or a
type (after promotion) not expected by a function with variable number
of arguments, the behavior is undefined.

The string functions as does fclose, do not specify behavior for
being passed null behavior, hence by 7.1.4 the behavior is undefined.


I think you two are in violent agreement.

:P

Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Feb 14 '06 #14

P: n/a

Ron Natalie wrote:
Default User wrote:
Jakob Bieling wrote:

Guess I am just complaining about them writing "any error", when in
fact passing a 0-pointer is not covered.

Many functions, especially those inherited from C, accept null pointers
without defined behavior. Notably most of the C-style string functions.

Absolutely, completely wrong.


I don't think so!
7.1.4 of the C standard says that:

If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer outside the address
space of the program, OR A NULL POINTER, or a pointer to on-modifiable
storage when the corresponding parameter is not const-qualified) or a
type (after promotion) not expected by a function with variable number
of arguments, the behavior is undefined.
Which is what I said, more or less.
The string functions as does fclose, do not specify behavior for
being passed null behavior, hence by 7.1.4 the behavior is undefined.


That's what I said, "without defined behavior".

I believe you misread what I wrote. Probably my phrasing wasn't the
best.

Brian

Feb 14 '06 #15

P: n/a
Ben Pope wrote:
Ron Natalie wrote:
Default User wrote:
Many functions, especially those inherited from C, accept null
pointers without defined behavior. Notably most of the C-style
string functions.
The string functions as does fclose, do not specify behavior for
being passed null behavior, hence by 7.1.4 the behavior is
undefined.


I think you two are in violent agreement.

I believe so. My phrasing "without defined behavior" probably threw Ron
off in his reading.

I might screw up in the details of C++, but I'm unlikely to make a
fundamental error in C :)

Brian

Feb 14 '06 #16

P: n/a
Default User wrote:
Ben Pope wrote:
Ron Natalie wrote:
Default User wrote: Many functions, especially those inherited from C, accept null
pointers without defined behavior. Notably most of the C-style
string functions. The string functions as does fclose, do not specify behavior for
being passed null behavior, hence by 7.1.4 the behavior is
undefined.

I think you two are in violent agreement.

I believe so. My phrasing "without defined behavior" probably threw Ron
off in his reading.


Yes there term "accept" allowed me to gloss over the difference between
"defined" and "undefined". We are in "violent agreement."
Feb 15 '06 #17

P: n/a
Ron Natalie wrote:
Default User wrote:

I believe so. My phrasing "without defined behavior" probably threw
Ron off in his reading.


Yes there term "accept" allowed me to gloss over the difference
between "defined" and "undefined". We are in "violent agreement."


I was trying to avoid saying the Standard said it was UB, because in
most of these cases it just doesn't address what happens when you pass
in NULL. So I ended up with fairly clunky language that needed a
rewrite editor.

Brian
Feb 15 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.