Embedded systems (the ones where you would disallow malloc) don't generally have virtual memory by virtue of having no MMU, so on those you can't do overcommitment since there is no page fault mechanism.

No, the reason is simply that by statically allocating all memory you can avoid entire classes of program faults and bugs. There are no memory leaks and you don't need to solve the NP-complete problem of "is there an execution path where a dynamic memory allocation will fail". Keep in mind that it is not just about the total amount of dynamically allocated memory, but also the order of allocations (and frees).

That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification.

If you still need dynamic allocation, you might choose to have a custom allocator working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed).

(All that said, embedded systems sometimes don't have virtual memory, so the original problem stated in the link is just not a thing...)

> working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed)

And I should add to this that you probably want to access all of the pool/arena to do setup, or just ensure it's physically allocated if you are running in a virtual memory space. This is something that is reasonable at setup time, though.

All good stuff.

I’m working on a project now and trying my best to make it MISRA compatible because FreeRTOS did the same. You don’t use malloc() but rather pvPortMalloc() which pulls from an already allocated pool. Their HEAP4 system tries to keep the chunks organized. So far I’ve been very happy with it.

I wouldn't say this is the reason. Embedded systems typically don't have virtual memory to start.

I would expect (but verify) a malloc implementation on embedded to return null if it can't satisfy the allocation.

But even with that assumption malloc in embedded is often a bad idea. You need to plan for worst case anyway and you can not afford memory fragmentation.

Aside from the fact that overcommit usually doesn't apply to embedded systems, malloc() is fine; its free() that is the problem.

I'd love to see how people design software with fully static memory (and limited one at that)

You can find a number of technical deep-dives for classic video game consoles where people have had do deal with very limited resources.

This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE

cool, I should dig about that sub topic too.