Memory leak proof every C program • Hacker News Board

Re: Memory leak proof every C program

#41

Post by rco8786 » Sat, Jan 20, 2024, 10:35 PM UTC

enriquto wrote: post #3

This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…

Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.

Re: Memory leak proof every C program

#42

Post by skrebbel » Sat, Jan 20, 2024, 10:43 PM UTC

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

Re: Memory leak proof every C program

#43

Post by marcodiego » Sat, Jan 20, 2024, 10:46 PM UTC

enriquto wrote: post #3

This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…

Actually that is not too far from reality. Data that will be allocated only once does not need be freed. You really only need to free memory that may increase iteratively. If the memory is not used frequently it will end up on swap without major implications. If it is used during the whole execution, it will only be freed when the program ends; there's difference if it's by a 'free' or by the OS; there's just no difference.

As an example, constant data that is allocated by GNU Nano is never freed. AFAIK, the same happens when you use GTK or QT; there were even tips on how to suppress valgrind warnings when using such libs.

Re: Memory leak proof every C program

#44

Post by deviantbit » Sat, Jan 20, 2024, 10:47 PM UTC

nektro wrote: post #15

deviantbit wrote: post #4

[flagged]

U+1F926 U+200D U+2640 U+FE0F

Thanks.

Re: Memory leak proof every C program

#45

Post by weinzierl » Sat, Jan 20, 2024, 10:48 PM UTC

enriquto wrote: post #3

This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…

The go guys knew this all along, because if I understood it correctly this is what happens when you disable the garbage collector. Voila, now you can claim your garbage collector is totally optional and your language fundamentally doesn't require a garbage collector.

[I love golang, and I think it's one of the best languages around. If only it had a truly optional garbage collector. But then again, it wouldn't be go I guess...]

Re: Memory leak proof every C program

#46

Post by avgcorrection » Sat, Jan 20, 2024, 10:50 PM UTC

linkdd wrote: post #26

klyrs wrote: post #7

Earlier quoted context omitted.

In the not-rare case where you're writing a library, or wrapping a utility, the last programmer's exhilaration is your pain.

If you're writing a library, you're not writing a program. If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.

Yeah I don’t know how a C library without `_free()` calls would work across FFI (like making bindings).

Re: Memory leak proof every C program

#47

Post by deviantbit » Sat, Jan 20, 2024, 10:50 PM UTC

Sakos wrote: post #14

I'm concerned about how a non-zero number of people here on HN seem to think this is meant seriously.

What is astonishing are those that think this is a serious solution.

Re: Memory leak proof every C program

#48

Post by Waterluvian » Sat, Jan 20, 2024, 10:50 PM UTC

“Hey I might need that later!”

Memory hoarding. I hate it but I love it.

Re: Memory leak proof every C program

#49

Post by tonyedgecombe » Sat, Jan 20, 2024, 10:56 PM UTC

skrebbel wrote: post #42

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

Are you saying PHP creates a new process for each request?

Re: Memory leak proof every C program

#50

Post by tonyedgecombe » Sat, Jan 20, 2024, 10:58 PM UTC

TillE wrote: post #24

I used to really struggle with memory leaks in C++, until smart pointers came along. I think the only leak I've investigated since then wound up being an actual bug in the MSVC standard library. OS handles and such are still an issue, but you can wrap them too. Thank goodness for RAII, a fantastic reason to use C++ even if you're otherwise writing C-like code.

As long as you don’t forget to make your destructors virtual.