«

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 what happens in memory operations, everyone knows the importance
of
freeing the allocated memory, but there do have memory leaks from time
to
time! For the memory leak case, there are lots of testing tools to
detect it
automatically like Rational Purify or other free ones.

So my question is: is there any testing tool right there which can
detect
forgetting-fclose defects automatically?

I have searched google pages and groups but seem to get no hint!

Any help will be greatly appreciated!

lihua wrote:
> 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 what happens in memory operations, everyone knows the
> importance of freeing the allocated memory, but there do have memory leaks
> from time to time! For the memory leak case, there are lots of testing tools
> to detect it automatically like Rational Purify or other free ones.
>
> So my question is: is there any testing tool right there which can
> detect forgetting-fclose defects automatically?

In most C libraries, fopen() allocates memory for the FILE * structure
it returned expecting fclose() to deallocate it. In other words, the
best tool is something like Purify.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Hi
You can use dev partner .. it may be useful to find such kind of
problems
Mayur

lihua wrote:
>
> 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 what happens in memory operations, everyone
> knows the importance of freeing the allocated memory, but there do
> have memory leaks from time to time! For the memory leak case,
> there are lots of testing tools to detect it automatically like
> Rational Purify or other free ones.
>
> So my question is: is there any testing tool right there which can
> detect forgetting-fclose defects automatically?

If you keep track of what you are doing there should be no
problem. However if you need to protect against your own
sloppiness, try this:

1. Wherever you declare the FILE* variable, initialize it to NULL.
2. Ensure that that scope has a single exit point.
3. At that exit, insert "if (f) fclose(f)", where f is the FILE*
variable.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer <> writes:
> lihua wrote:
> >
> > 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!

Be careful when you use FILE objects then

> > Just like what happens in memory operations, everyone knows the
> > importance of freeing the allocated memory, but there do have memory
> > leaks from time to time! For the memory leak case, there are lots of
> > testing tools to detect it automatically like Rational Purify or
> > other free ones.
> >
> > So my question is: is there any testing tool right there which can
> > detect forgetting-fclose defects automatically?
>
> If you keep track of what you are doing there should be no
> problem. However if you need to protect against your own
> sloppiness, try this:
>
> 1. Wherever you declare the FILE* variable, initialize it to NULL.

This is almost very good advice, but it's just a half-measure though and
hardly a solution to the real problem which is sloppiness when using
FILE objects. Initializing FILE pointers to NULL when they are
declared, i.e. with something like this:

1 #include <stdio.h>
2
3 int main(void)
4 {
5 FILE *fp = NULL;
6 int k;
7

will only serve as a warning the first time `fp' has to be accessed.

If the `fp' pointer is used in a loop and gets assigned to the result of
multiple fopen() calls, the second and all subsequent calls will not
have a NULL `fp' as an indication of something that is wrong with the
program:

8 for (k = 1; k < argc; k++) {
9 if (argv[k] == NULL)
10 continue;
11 fp = fopen(argv[k], "rb");
12
13 /* Do something with `fp' here. */
14
15 /* Missing fclose() call. */
16 }
17
18 return (EXIT_SUCCESS);
19 }

The only way to avoid leaking open FILE objects here is to be careful
when writing the program.

Instead of the original suggestion (Wherever you declare the FILE*
variable, initialize it to NULL), I usually prefer to "initialize
pointers to known values right before you start using them and use
assert() to watch out for 'strange' values in strategically chosen
places".

- Giorgos

Giorgos Keramidas wrote:
> CBFalconer <> writes:
>> lihua wrote:
>>>
>>> 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!
>
> Be careful when you use FILE objects then
>
>>> Just like what happens in memory operations, everyone knows the
>>> importance of freeing the allocated memory, but there do have memory
>>> leaks from time to time! For the memory leak case, there are lots of
>>> testing tools to detect it automatically like Rational Purify or
>>> other free ones.
>>>
>>> So my question is: is there any testing tool right there which can
>>> detect forgetting-fclose defects automatically?
>>
>> If you keep track of what you are doing there should be no
>> problem. However if you need to protect against your own
>> sloppiness, try this:
> >
> > 1. Wherever you declare the FILE* variable, initialize it to NULL.
>
> This is almost very good advice, but it's just a half-measure though and
> hardly a solution to the real problem which is sloppiness when using
> FILE objects. Initializing FILE pointers to NULL when they are
> declared, i.e. with something like this:

You miss the point, and snipped the example. Initializing to NULL
at declaration means you can tell whether it was used at scope
exit, and thus can safely call fclose on it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer <> writes:
>Giorgos Keramidas wrote:
>> CBFalconer <> writes:
>>> lihua wrote:
>>>>
>>>> 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!
>>
>> Be careful when you use FILE objects then
>>
>>>> Just like what happens in memory operations, everyone knows the
>>>> importance of freeing the allocated memory, but there do have memory
>>>> leaks from time to time! For the memory leak case, there are lots of
>>>> testing tools to detect it automatically like Rational Purify or
>>>> other free ones.
>>>>
>>>> So my question is: is there any testing tool right there which can
>>>> detect forgetting-fclose defects automatically?
>>>
>>> If you keep track of what you are doing there should be no
>>> problem. However if you need to protect against your own
>>> sloppiness, try this:
>> >
>> > 1. Wherever you declare the FILE* variable, initialize it to NULL.
>>
>> This is almost very good advice, but it's just a half-measure though and
>> hardly a solution to the real problem which is sloppiness when using
>> FILE objects. Initializing FILE pointers to NULL when they are
>> declared, i.e. with something like this:
>
> You miss the point, and snipped the example. Initializing to NULL
> at declaration means you can tell whether it was used at scope
> exit, and thus can safely call fclose on it.

I wasn't clear enough it seems. Checking at scope exit breaks
immediately the moment you start calling fopen() inside loop constructs.

You *are* right that checking at scope exit is good. I'm not arguing
against that. I'm merely pointing out that it's not a panacea.

Regards,
Giorgos

"CBFalconer" <> wrote in message
news:...
> Giorgos Keramidas wrote:
>> CBFalconer <> writes:
>>> lihua wrote:
>>>>
>>>> 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!
>>
>> Be careful when you use FILE objects then
>>
>>>> Just like what happens in memory operations, everyone knows the
>>>> importance of freeing the allocated memory, but there do have memory
>>>> leaks from time to time! For the memory leak case, there are lots of
>>>> testing tools to detect it automatically like Rational Purify or
>>>> other free ones.
>>>>
>>>> So my question is: is there any testing tool right there which can
>>>> detect forgetting-fclose defects automatically?
>>>
>>> If you keep track of what you are doing there should be no
>>> problem. However if you need to protect against your own
>>> sloppiness, try this:
>> >
>> > 1. Wherever you declare the FILE* variable, initialize it to NULL.
>>
>> This is almost very good advice, but it's just a half-measure though and
>> hardly a solution to the real problem which is sloppiness when using
>> FILE objects. Initializing FILE pointers to NULL when they are
>> declared, i.e. with something like this:
>
> You miss the point, and snipped the example.
You didn't provide an example, and then snipped his!

> Initializing to NULL
> at declaration means you can tell whether it was used at scope
> exit, and thus can safely call fclose on it.

Not necessarily... fclose may have already been called (pointer not reset)

consider
void func(void)
{
FILE *fp = NULL;
for(; {
...
if((fp = fopen(file, "r")) != NULL) {
...
fclose(fp);
}
...
break;
}
if(fp) // will probably be set
fclose(fp); // shouldn't be called
return;
}


Regards,
Mark

Giorgos Keramidas wrote:
> CBFalconer <> writes:
>> Giorgos Keramidas wrote:
>>> CBFalconer <> writes:
>>>> lihua wrote:
>>>>>
.... snip ...
>>>>>
>>>>> So my question is: is there any testing tool right there which
>>>>> can detect forgetting-fclose defects automatically?
>>>>
>>>> If you keep track of what you are doing there should be no
>>>> problem. However if you need to protect against your own
>>>> sloppiness, try this:
>>>>
>>>> 1. Wherever you declare the FILE* variable, initialize it to NULL.

*** Restored snippage so things make sense to others ***
2. Ensure that that scope has a single exit point.
3. At that exit, insert "if (f) fclose(f)", where f is the
FILE* variable.
*** End of restored snippage ***

>>>
>>> This is almost very good advice, but it's just a half-measure though
>>> and hardly a solution to the real problem which is sloppiness when
>>> using FILE objects. Initializing FILE pointers to NULL when they
>>> are declared, i.e. with something like this:
>>
>> You miss the point, and snipped the example. Initializing to NULL
>> at declaration means you can tell whether it was used at scope
>> exit, and thus can safely call fclose on it.
>
> I wasn't clear enough it seems. Checking at scope exit breaks
> immediately the moment you start calling fopen() inside loop
> constructs.
>
> You *are* right that checking at scope exit is good. I'm not
> arguing against that. I'm merely pointing out that it's not a
> panacea.

You still miss the point. Any successful fopens, within loops or
elsewhere, will leave the pointer non-NULL, so the scope exit code
can tell that a fclose is needed. Any successful earlier fcloses
within that scope need to also set the pointer to NULL. The state
of the pointer, NULL or non-NULL, signals whether it refers to an
open file. This way the scope will _never_ exit leaving unclosed
abandoned files behind, which was the OPs objective.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer <> writes:
> CBFalconer <> writes:
> > If you keep track of what you are doing there should be no
> > problem. However if you need to protect against your own
> > sloppiness, try this:
> >
> > 1. Wherever you declare the FILE* variable, initialize it to NULL.
>
> *** Restored snippage so things make sense to others ***
> 2. Ensure that that scope has a single exit point.
> 3. At that exit, insert "if (f) fclose(f)", where f is the
> FILE* variable.
> *** End of restored snippage ***

CBFalconer <> writes:
> Giorgos Keramidas writes:
> > CBFalconer <> writes:
> > > Giorgos Keramidas writes:
> > > > This is almost very good advice, but it's just a half-measure though
> > > > and hardly a solution to the real problem which is sloppiness when
> > > > using FILE objects. Initializing FILE pointers to NULL when they
> > > > are declared, i.e. with something like this:
> > >
> > > You miss the point, and snipped the example. Initializing to NULL
> > > at declaration means you can tell whether it was used at scope
> > > exit, and thus can safely call fclose on it.
> >
> > I wasn't clear enough it seems. Checking at scope exit breaks
> > immediately the moment you start calling fopen() inside loop
> > constructs.
> >
> > You *are* right that checking at scope exit is good. I'm not
> > arguing against that. I'm merely pointing out that it's not a
> > panacea.
>
> You still miss the point. Any successful fopens, within loops or
> elsewhere, will leave the pointer non-NULL, so the scope exit code
> can tell that a fclose is needed. Any successful earlier fcloses
> within that scope need to also set the pointer to NULL. The state
> of the pointer, NULL or non-NULL, signals whether it refers to an
> open file. This way the scope will _never_ exit leaving unclosed
> abandoned files behind, which was the OPs objective.

Of course the "scope may exit", depending on the definition of "scope"
you use and the placement of the (FILE *) object's declaration, i.e. the
"scope" of a (FILE *) is not necessarily the loop construct, unless you
are referring to declarations like:

while (1) {
FILE *fp = NULL;

if ((fp == fopen(...) == NULL)
break;

/* Some code that uses `fp'. */
if (fp != NULL)
fclose(fp);
}

The same is not true though for declarations like the one I presented in
a previous post:

{
FILE *fp = NULL;

while (1) {
if ((fp = fopen(...)) == NULL)
break;

/* Do something with fp. */
fclose(fp);
}
}

In this second case, it's the responsibility of the programmer to make
sure tha every fopen() has a matching fclose(). The same responsibility
falls on the shoulders of the programmer when the fopen() and fclose()
call are wrapped around higher level interfaces, like for example:

FILE *libfoo_openlog(const char *filename);
void libfoo_closelog(FILE *fp);

Anyway, this already feels like a rather pointless argument, so I'm not
going to post anything else in this thread.

- Giorgos