fopen and fclose?

[kathy]

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);
}

[DraakUSA]

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.

[mlimber]

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

[Victor Bazarov]

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

[mlimber]

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.

[mlimber]

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

[Default User]

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)

[Jakob Bieling]

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)

[Default User]

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)

[Roland Pibinger]

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

[Jakob Bieling]

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)

[Default User]

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

[Ron Natalie]

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.

[Ben Pope]

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

[Default User]

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

[Default User]

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

[Ron Natalie]

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."

[Default User]

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