3 ms·

I may be wrong, but my C teacher in college told me that was a leak.

by xena 6y ago

chrismorgan 6y ago
I’m with shawnz. If it’s a global/static, and you’re the entire process, freeing it is altogether a waste. Actually, if you have actual destructors, it’s even potentially hazardous. Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. It offers this explanation: https://doc.rust-lang.org/1.6.0/complement-design-faq.html#there-is-no-life-before-or-after-main-no-static-ctorsdtors https://doc.rust-lang.org/1.6.0/complement-design-faq.html#t... (link is to the Rust 1.6 docs; in theory by the next release the content was ported to the main site, but I can’t find it and suspect it got lost at some point). Now if you’re a library, then having the ability to deinitialise your library might be useful. Probably not, but it might be.
- 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 ago
    Who 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.
- haberman 6y ago
  > Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. I would be surprised if embedding a string literal into a Rust program would cause a runtime dynamic memory allocation. There is no reason for that: it can be embedded into the binary as static constant-initialized data. So I would presume the opposite: I would expect that the comparable Rust program would not fail this Valgrind test, because it would not perform any dynamic memory allocation at all. I don't know anything about V, but I would similarly wonder why this program requires malloc().
  - chrismorgan 6y ago
    This is true; I contemplated it but decided not to mention it. I haven’t looked into why this V program would be allocating, but I agree with you that the equivalent Rust program would not allocate for this. I decided instead to focus just on the matter of what happens if you do allocate in such a global—which Rust doesn’t let you do directly, you deliberately have to use a trick like lazy_static which constructs on first use and then deliberately leaks so that it never has to destroy.
    - xena 6y ago
      I admit I was wrong, I will use this information in the future to make my blogposts better.

I may be wrong, but my C teacher in college told me that was a leak.

by xena 6y ago

I may be wrong, but my C teacher in college told me that was a leak.

I’m with shawnz. If it’s a global/static, and you’re the entire process, freeing it is altogether a waste. Actually, if you have actual destructors, it’s even potentially hazardous. Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. It offers this explanation: https://doc.rust-lang.org/1.6.0/complement-design-faq.html#there-is-no-life-before-or-after-main-no-static-ctorsdtors https://doc.rust-lang.org/1.6.0/complement-design-faq.html#t... (link is to the Rust 1.6 docs; in theory by the next release the content was ported to the main site, but I can’t find it and suspect it got lost at some point). Now if you’re a library, then having the ability to deinitialise your library might be useful. Probably not, but it might be.

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 ago
  Who 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.
haberman 6y ago
> Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. I would be surprised if embedding a string literal into a Rust program would cause a runtime dynamic memory allocation. There is no reason for that: it can be embedded into the binary as static constant-initialized data. So I would presume the opposite: I would expect that the comparable Rust program would not fail this Valgrind test, because it would not perform any dynamic memory allocation at all. I don't know anything about V, but I would similarly wonder why this program requires malloc().
- chrismorgan 6y ago
  This is true; I contemplated it but decided not to mention it. I haven’t looked into why this V program would be allocating, but I agree with you that the equivalent Rust program would not allocate for this. I decided instead to focus just on the matter of what happens if you do allocate in such a global—which Rust doesn’t let you do directly, you deliberately have to use a trick like lazy_static which constructs on first use and then deliberately leaks so that it never has to destroy.
  - xena 6y ago
    I admit I was wrong, I will use this information in the future to make my blogposts better.