Yeah, but it's nicer to define that kind of stuff in your linker script IMO, where sizes of large memory regions can be thought of holistically.

The parent post was talking about using malloc once at the start of the program, are you talking about defining that with your linker script?

Also if the goal is to get one chunk of memory with a single call, why use malloc at all? Why not use the direct memory mapping command?

I don't think he's talking about using malloc "once", he's talking about only using it during init. In practice you end calling it a bunch in that model, the last design I shipped like that ended up making a few hundred malloc (well new operator because this was C++) calls at init.

Under that system malloc/new was just a pointer bump, and an assert if there wasn't enough room. Free wasn't linked, and delete asserted. That heap region (or mine had several heaps that lived in different memory with different characteristics that could be specified with a new overload) is way easier to define in your linker.

Of course, but then we are back to memory pools.

What is the difference between allocating memory right when the program starts with malloc and using the same size in static unitialized byte arrays?

There are differences of course, but that memory can be used in the same way, and so memory pools are orthogonal to how the memory is aquired.

If you use modules with opaque pointers, the types are incomplete and therefore their size is not known outside of the module. You can either make the type visible (against the idea of opaque pointers), modify the module to allocate a fixed set of instances (somewhat against the open/closed principle), or you let the module use malloc to allocate memory for new instances.

Why would someone be doing this while trying to fit within the boundaries of the MISRA standard? Also what do you mean by module?

The rule you are referring to is a "required" (not a "mandatory") rule. You can deviate from it and still be MISRA-C compliant. People write deviations for all kinds of reasons. Here are some rationales for deviations: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf (Rule 5 on page 10 on malloc) https://www.keil.com/pack/doc/CMSIS/Core/html/coreMISRA_Exce...

The unit of reuse that defines the type, example: http://c-faq.com/struct/sd1.html

So your solution, in a thread about using a fixed amount of memory, is to do nothing different and let anything use the heap at any time because it might be possible in some cases to get it past MISRA standards? I'm not really sure of what you are trying to say, it seems you keep skewing further from the original discussion.