3 ms·
Failing Valgrind is surely not a state in which neither a serious program should be nor the code produced by it. Most programs and their results that are in ser
by acqq 6y ago
Failing Valgrind is surely not a state in which neither a serious program should be nor the code produced by it. Most programs and their results that are in serious use are actually regulaly tested with Valgrind and therefore don't have such elementary failures, unless they aren't maintained.
It doesn't have to be "a library" -- as soon as you want to test it, you don't want it to fail the trivial tests. Nobody wins anything by keeping that in that state.
- shawnz 6y agoWho says having "still reachable" memory in your Valgrind output is a "fail" though? Look at this excerpt from the Valgrind manual: > Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. So, by default, Memcheck won't report such blocks individually. https://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks https://www.valgrind.org/docs/manual/mc-manual.html#mc-manua...
- delian66 6y ago> Most programs and their results that are in serious use are actually regulaly tested with Valgrind See https://github.com/vlang/v/tree/master/vlib/v/tests/valgrind https://github.com/vlang/v/tree/master/vlib/v/tests/valgrind . The automatic memory management is work in progress right now, but we do have a growing battery of tests for it. I currently would not use V for a long running program for exactly that reason, unless it is a very simple service and I free everything manually. That said its -autofree mode is improving daily.