Hacker News Reader

Comment by immibis | Hacker News Reader

There is no safe, reliable, cross-environment way to deal with deallocating memory. A memory block can be referenced from arbitrary locations, some of which may be on the stack by clients of the memory block when it isndeallocated.

The only safe, consistent, reliable approach is not to deallocate memory.

View on HN

The difference is that memory won't do anything under your nose, it can't run arbitrary code by itself. It won't spawn threads, create thread locals, or store data in global variables. And it's normal to track the lifetime of memory, much less the lifetime of code and function pointers passed around.

The same is true of DLLs. They don't do anything by themselves; they are merely blocks of bytes mapped into memory.

Why is tracking the lifetime of a function pointer different from tracking the lifetime of any other pointer?

FreeLibrary on Windows unloads libraries when the reference count is zero.

> The same is true of DLLs. They don't do anything by themselves; they are merely blocks of bytes mapped into memory.

FYI just loading a DLL can execute code.

> Why is tracking the lifetime of a function pointer different from tracking the lifetime of any other pointer?

Technically speaking none, but historically this is something that nobody did, so we are full of code that assumes function pointers to have a static lifetime. It's a social problem.

You could do that, but then you're running valgrind.

It seems like the major problem here was blindly calling an init function and then completely failing when it returned a non standard result.

The init function could return a status that indicates "already initialized."

The calling code could observe this and passively warn of the unusual condition but otherwise proceed.

You joke, but there are programs that do exactly this.

Reply on news.ycombinator.com