> Programs built with the V compiler no longer leak memory by default.
What?
What?
https://github.com/vlang/v/issues/9327
At the end of the thread, medvednikov wrote this just before closing the issue:
> “Zero leaks when using autofree which will become the default in 0.3:”
I guess they did make autofree enabled by default in this release.
If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim:
> “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.”
> https://github.com/vlang/v/blob/master/doc/docs.md#control
You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.
There are no leaks by default now. If you want manual memory management, you can do that.
What's the problem?
And hello world hasn't been leaking for a while now, it was just an unfreed global const.
The issue you referenced, wasn't closed as a wontfix. It was closed because it was fixed.
However, I just checked, and the 0.3 release does leak even without -manualfree!
lxc launch images:debian/bullseye test-v
lxc exec test-v bash
# Inside the container:
apt install build-essential git valgrind
git clone https://github.com/vlang/v
cd v
git rev-parse HEAD
# 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136
make
# ...
# Your `tcc` is working. Good - it is much faster at compiling C source code.
# V has been successfully built
# V 0.3.0 74bb5ae
./v examples/hello_world.v
valgrind --leak-check=yes examples/hello_world
# ... report about invalid read of size 1.
# ... reports about uninitialized values.
# ==5750== LEAK SUMMARY:
# ==5750== definitely lost: 0 bytes in 0 blocks
# ==5750== indirectly lost: 0 bytes in 0 blocks
# ==5750== possibly lost: 1,360 bytes in 5 blocks
# ==5750== still reachable: 0 bytes in 0 blocks
# ==5750== suppressed: 0 bytes in 0 blocks
# ...
# ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0)
apt install wget unzip
rm v -r
wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip
sha1sum v_linux.zip
# bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip
unzip v_linux.zip
cd v
./v examples/hello_world.v
valgrind --leak-check=yes examples/hello_world
# Exact same result as above, just a different PID of course.
==3494== in use at exit: 0 bytes in 0 blocks
==3494== total heap usage: 6 allocs, 6 frees, 2,912 bytes allocated
==3494==
==3494== All heap blocks were freed -- no leaks are possible
==3494== ERROR SUMMARY: 260 errors from 5 contexts (suppressed: 0 from 0)
I think perhaps correctly(?) The allocations are freed when running the flag "-prod" for compiling. When this flag isn't passed, you end up with:
"total heap usage: 26 allocs, 11 frees, 8,702 bytes allocated"