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