Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory leak proof every C program

flak.tedunangst.com

Post reply on HN
Print view View original

51–60 of 175 posts

Re: Memory leak proof every C program

#51

Post by HideousKojima »

rco8786 wrote: post #41
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.

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...

Re: Memory leak proof every C program

#53

Post by [deleted] »

rco8786 wrote: post #41
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.

[deleted]

Re: Memory leak proof every C program

#54

Post by kbenson »

MrJohz wrote: post #30
linkdd wrote: post #26

Earlier quoted context omitted.

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*.

Any large program is composed of libraries. They may not explicitly be described as libraries, or imported from external sources, but there will be abstraction boundaries somewhere. Which means that if you're writing a program, you probably are also writing one or more libraries.

The difference is that if you're writing a program you know the scope of use of all libraries, whether they be externally loaded or internal abstraction boundaries, and also know the scope of use of the program, and can make a call as to whether cleanup during opetation is required.

Re: Memory leak proof every C program

#56

Post by msla »

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.

Re: Memory leak proof every C program

#57

Post by jnwatson »

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...

There was a certain Space Shuttle program that never returned from interrupt. At the end of its interrupt handler, it would just spin. The next interrupt would just add to the call stack.

What happens when it runs out of stack? It just resets the stack pointer back to the start.

Re: Memory leak proof every C program

#58

Post by the-smug-one »

avgcorrection wrote: post #46
linkdd wrote: post #26

Earlier quoted context omitted.

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).

Why would FFI be an issue?

Re: Memory leak proof every C program

#59

Post by ahoka »

rco8786 wrote: post #41
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.

It’s available from Java 11 as the Epsilon GC.

Re: Memory leak proof every C program

#60

Post by SPascareli13 »

tonyedgecombe wrote: post #49
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?

It's been a while since I used PHP, but this is something controlled by the server used. If you use Apache then it used to create a new process for each request, yes.
Post reply on HN