Rich Burridge wrote:
> In this case, i's not a real problem (see below). I thought the goal here
> was to make our code Parfait clean.
Sorry, "real problem" was ambiguous. I didn't mean to ask whether it was
a safely ignorable problem (which it is), but whether it was technically a
bug in the code or a parfait false positive.
In such a simple case (fifty-line file that consists almost entirely of a
main() method), this can be determined simply by eye, and that's probably
all that needs to go into the bug ("FILE *fp opened on line X, never
explicitly closed, and a straight path through to the point where it should
be" or some such).
Some of the parfait errors in vim took me hours to track down, and I want
to make sure that that kind of analysis doesn't get lost, and that the bugs
that don't require such analysis get annotated with the simple analysis
that demonstrates how simple the bug is.
> >When you did your testing, did you see the file descriptor leak prior to
> >adding the fix, and see that it went away afterwards, or was your test
> >simply that aasavefont didn't break?
>
> You answered your own question with the comment below. The file
> descriptor will be automatically closed as the program exits. Parfait
> doesn't appear to have the smarts to understand that and deal accordingly.
I can agree with the fix by looking at it, but simply running the program
before and after the fix doesn't demonstrate that anything's changed, never
mind that a bug has been fixed. Part of your testing, of course, will be
to show that parfait doesn't complain after the fix, but the other part is
to demonstrate that the bug parfait found (file descriptor not being
closed) is no longer present -- truss output showing that the close happens
before main() returns, maybe?
I know this is a super-simple thing, and I don't want to overburden you
with a lot of paperwork for such a small problem, but I felt that it would
be easy to demonstrate on a simple case what ought to be done for these
bugs when they got more complicated.
Anyway, thanks for starting to tackle these guys.
Danek
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
