3 ms·
I've written plenty of embedded code where the first rule was "Thou shall not malloc." In just about every case it turns into setting aside static buffers and
by adestefan 13y ago
I've written plenty of embedded code where the first rule was "Thou shall not malloc." In just about every case it turns into setting aside static buffers and doing manual structure allocation. This is such a common idiom in embedded systems that most RTOS systems have this functionality built-in.
- Nursie 13y agoThe embedded system I'm working right now doesn't have malloc as part of its platform SDK anyway, so it's not like there's a choice :) I guess it depends on what exactly you're working on, but passing in a stack-declared for a function to fill with its results seems better to me anyway, as general practice. Preferable to allocating a new structure in the function and then returning it, that is. There are no ownership issues and nobody has to remember to free anything. Heap emulation with static buffers comes with its own costs - either you end up writing an allocation engine or you just use a large buffer with an advancing pointer, free() does nothing and the whole thing has to be reset every so often, which means that you have to convince the other developers on the team that it's not to be used like normal malloc and please be careful and ... that's a whole other can of worms!