Tim Ruehsen <[email protected]> writes: > Then you don't close files, sockets, locks etc. either just because your are > in main ? IMHO, you should change your habits... ;-)
At some point, I choose to trust that the operating system and C library does its job. E.g, if I set the close-on-exec flag on some file descriptors, I don't try to close them explicitly between fork and exec. And "close-at-exit" seems like a more basic feature of the system. Then I'm aware that for output files, one ought to close them and check the return value. In particular if using FILE, since it's bad if closing fails silently due to full disks at the time buffered data is written out. But I guess one can't close the C library stdout; there, fflush is the best one can do. > 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 > ===================== I see. So from this perspective, it's desirable that the code path leading to exit(EXIT_SUCCESS) frees all allocated storage. While it doesn't matter for failure exits. And one ought to run the tests both with and without valgrind, to get proper testing also for testscases where programs are expected to fail (and I guess one could also make careful use of the value of the exit code, not jsut chek thhat it's non-zero). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
