Am Monday 10 September 2012 schrieb Niels Möller:
> > Are you going to say "ahhh, it is the main function - I don't need to
> > call free() here." ?
>
> Yes, I'd definitely say that. And I would expect a static analyzer to do
> the same (either by default, or with some reasonable command line flag).
> I have a hard time to view this as a memory leak or a problem at all.
Then you don't close files, sockets, locks etc. either just because your are
in main ? IMHO, you should change your habits... ;-)
As Simon Josefsson made clear, the main reason are automated tests for memory
leaks using valgrind. Something, that a library test suite should not miss.
In nettle/run-tests just replace the line
"$1" $testflags
by
valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes "$1"
$testflags
and 'make check':
...
=====================
36 of 51 tests failed
=====================
But without freeing resources in main(), you now can't easily say, if you have
a problem in the library or in the testsuite.
BTW, as you see, the static analyzers won't find all of these problems.
> I'm a bit curious on how you and the analyzer reason about the
> following three examples.
...
> Is there any good reason to say that that in one of these cases, it's a
> memory leak, while in some of the other cases, it is not?
>
> To arrange for proper freeing before program exit in case (3) (or more
> complex real programs with that pattern), one would have to add an
> atexit call in main and potentially also in lots of other functions
> doing allocation. That would really clutter the code, for very little
> benefit.
Yes and No. It really depends on what YOU - as the programmer - want.
For libraries functions I would say, they should never call exit() etc.
You normally have a matching pair of open/close, init/deinit etc. to be able
to control resource freeing.
For applications, programmers normally spend some afford to at least be able
to free all resources right before (non-error) exit(). To have at least some
test-cases to check for resource leaks. Especially long-running apps need
something like that.
If you decide, that 'emergency exits' on fatal errors doesn't have to free all
resources, that is perfectly fine. And I know of none project that doesn't
handle it in that practical way. Except libraries.
BTW, using the clang static analyzer is easy and straight forward.
- cd into nettle
- make clean
- scan-build ./configure
- scan-build make
scan-build: 3 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2012-09-11-1' to examine bug
reports.
- scan-view /tmp/scan-build-2012-09-11-1
Of course, there might be some false positives, but clang 3.1.1 does a pretty
good job.
There is also cppcheck, another static analyzer. It may find other things than
clang.
- cd into nettle
- cppcheck --enable=all .
e.g.:
[testsuite/yarrow-test.c:141]: (warning) %d in format string (no. 1) requires
a signed integer given in the argument list.
[testsuite/yarrow-test.c:163]: (warning) %d in format string (no. 1) requires
a signed integer given in the argument list.
[testsuite/yarrow-test.c:168]: (warning) %d in format string (no. 1) requires
a signed integer given in the argument list.
[testsuite/yarrow-test.c:202]: (warning) %d in format string (no. 1) requires
a signed integer given in the argument list.
[testsuite/yarrow-test.c:220]: (error) Resource leak: input
Happy bug hunting ;-)
Regards, Tim
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
