Memory leak proof every C program • Hacker News Board

Re: Memory leak proof every C program

#61

Post by enriquto » Sat, Jan 20, 2024, 11:17 PM UTC

msla wrote: post #56

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…

A great way to write horrible programs. In short: If it works until it crashes, it doesn't work.

TFA is clearly written in jest. The provided code is not supposed to be run in production, just to illustrate how easy is to trick a "leak detector" in your debugger. You just put all your mallocs in a list, and at the end of your program you can free them all.

Yet, the idea of not freeing some memory in your program is not entirely stupid. Unless your memory is allocated inside a loop of unpredictable length, it's not really necessary to ever free it. Worse: the call to "free" may even fall after your program has run successfully. Thus, avoiding the useless (but typical) freeing spree at the end of your program may make it more robust!

Re: Memory leak proof every C program

#62

Post by Voultapher » Sat, Jan 20, 2024, 11:19 PM UTC

_a_a_a_ wrote: post #40

neonscribe wrote: post #31

Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.

It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Sometimes leaking is very tolerable and in terms of programmer time, very cheap!

I think the mold linker does this.

Re: Memory leak proof every C program

#63

Post by didgetmaster » Sat, Jan 20, 2024, 11:22 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…

>In the rare cases where your program needs to be long-running, leaks may become a real problem.

Where did this idea come from? I have seen leaks where a program can consume all available memory in just a few seconds because the programmer (definitely not me...) forgot to free something in a function called millions of times.

Re: Memory leak proof every C program

#64

Post by tetromino_ » Sat, Jan 20, 2024, 11:23 PM UTC

HideousKojima wrote: post #51

rco8786 wrote: post #41

Earlier quoted context omitted.

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.

Or the missile firmware where the missile is going to explode before they run out of memory: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.

Re: Memory leak proof every C program

#65

Post by layer8 » Sat, Jan 20, 2024, 11:27 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…

This is just an arena allocator scoped to the process.

Re: Memory leak proof every C program

#66

Post by x86x87 » Sat, Jan 20, 2024, 11:27 PM UTC

Since this seems to be some sort of joke i'm going to provide a "real" answer: write modular software where you can verify that each module is leak proof + use valgrind to actually track and verify you don't have links.

I have written medium to large projects using this approach and a leak-free program is not outside the realm of possible

Re: Memory leak proof every C program

#67

Post by zokier » Sat, Jan 20, 2024, 11:27 PM UTC

zeroCalories wrote: post #38

While subtle, your point was not lost on me! Technically all pointers are accessible, but the issue remains that we have not logically accounted for unused resources and are wasting capacity. In this sense, memory leaks are possible in all languages. We could store every object into a global structure, and it will never be freed in any language. Thus, my Rust program balloons forever.

> Thus, my Rust program balloons forever.

I get the feeling that this might have been response to recent "memory leak" thread(s): https://news.ycombinator.com/item?id=39041520

Re: Memory leak proof every C program

#68

Post by toasterlovin » Sat, Jan 20, 2024, 11:34 PM UTC

zanderwohl wrote: post #35

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 Zig compiler does this on purpose in some cases, iirc. Free can be a waste of time if the program is going to die in half a second from now.

Yeah, I first came across this strategy as a performance optimization in something Jared Sumner wrote about Bun (which is written in Zig).

Re: Memory leak proof every C program

#69

Post by alexgartrell » Sat, Jan 20, 2024, 11:36 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…

A professor actually told us that freeing prior to exit was harmful, because you may spend all of that time resurrecting swapped pages for no real benefit.

Counterpoint is that debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit

Re: Memory leak proof every C program

#70

Post by avgcorrection » Sat, Jan 20, 2024, 11:38 PM UTC

the-smug-one wrote: post #58

avgcorrection wrote: post #46

Earlier quoted context omitted.

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

Why would FFI be an issue?

Maybe you allocate a string and pass it to Rust code. Then the Rust code needs a way to free it (through `drop`).