Skip to content

Comment on JPL C Coding Standard [pdf]parent

Comments

That sorta goes hand-in-hand with "There shall be no use of dynamic memory allocation after task initialization." Which in my experience is the harder rule to deal with. It's not that often that you really truly need recursion. It happens, just not often. But no allocations, that radically changes how one codes.

But, these rules are for safety on embedded systems with very small amounts of memory. These represent the best lessons learned, the best ways to guarantee your function will finish in finite time and not run out of memory.

"But no allocations, that radically changes how one codes."

But this does not forbid implementing ones own memory manager that uses blocks from a huge continuous buffer.

True. Though I don't work at JPL or speak to what they would allow or forbid, but if you did implement your own memory manager, I imagine that you'd still need to write code that guarantees it will never run out, which might be harder to do if you have this abstraction. The spirit of these rules is to be enable code writing that is obviously correct and finite in time and space, at a glance.

So I'm in pure speculation land here, but I could see JPL frowning on rolling your own memory manager. Though I also imagine many applications of these rules happen on hardware that is small enough to make writing a memory manager overkill anyway.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.