That also doesn't make sense. You commonly have a heap but no runtime allocation under such circumstances.
MISRA, JSF C++, and even NASA code guidelines say no dynamic allocation after initialization.
If it's written in C or C++, that's also crazy town, and you're pretty much guaranteed to have dangling pointers as auto allocated objects are left behind on old stack frames.
I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc. It's not like you're calling alloca and letting those pointers escape -- any (valid) pointer you might have is to a static allocation or memory mapped address.
C++ is a different game and I don't know anything about it though.
But yeah the way I read this is they don't use malloc, which is pretty standard. This is how I've heard it referred to many times, and nothing else makes any sense.
> I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc.
I mean, it's common enough that MISRA, the JSF standard, and the NASA standard all specifically call it out to allow it under these conditions.
> It's not like you're calling alloca and letting those pointers escape -- any (valid) pointer you might have is to a static allocation or memory mapped address.
You only need to call alloca on dynamically sized stack allocations. You can always leak pointers to fixed size objects by:
void* woah_dont_do_this(void) {
int value = 0;
return &value;
}
and boom, the pointer that gets returned is pointing at invalid memory. Of course, no one would write it like this, but it's way easier than you might think to accidentally do this once there's some abstraction.
Nah, you can still call malloc/new. Worked on a sweet RTOS that had tons of default overrides for new that ultimately let you define all layout from your top level module despite following these guidelines. Let you share tons of code across boards, but still make decisions like "this guy's buffers should be this big, and stored in this ram bank" all from the top level C++ file for each board.
And it's definitely not stack allocated like the original point of this thread.
Well but regardless, if you have a malloc or new implementation that uses a static buffer, then you're still not touching the heap. In fairness and as you point out, it's not the stack either, but they're obviously not letting stack allocations escape. Nothing would ever work.
