Hello Strahinja,
in many cases it is clear that cleaning up resources is imperative -
for example in a program that completed one task and proceeds to
another task - yet many people neglect that; i'm not trying to justify
such neglect or to justify memory leaks.
I also agree with you that occasionally, edge cases occur where
the decision whether some resource should be cleaned up is not
trivial - for example if a long-running program uses one copy
of a small, global struct that can never reasonably be freed
while the program is doing any work, and for some reason is hard
to free at all, even before normal program termination.
Then it may sometimes be justifyable to simply leak it -
but such edge cases do not occur all that frequently.
My point is that a rule "always free everything, even after a
fatal error has occurred" is not a good rule for the explained
reasons.
Automatic tools for code inspection can indeed be one among several
instruments of quality control, in particular to more easily and
more quickly find candidate sites for code auditing.
But such tools are almost never perfect, and following their
advice slavishly is usually a bad idea.
Cases exist where freeing resources is clearly pointless and
even detrimental, in particular just before error exit.
I doubt the wisdom of advice like "people often fail to do X where
they have to, so tell them to do X even where it's detrimental,
because that might improve the chances that it gets done
when it is needed."
Exaggerated rules do not help the required human judgement.
Yours,
Ingo
No comments:
Post a Comment