3 ms·

As a side note for people like me who have no option other than C for their safety critical projects, remember there's a MISRA-C standard. If that feels too muc

As a side note for people like me who have no option other than C for their safety critical projects, remember there's a MISRA-C standard. If that feels too much, [1] is a good starting point. [1] http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf http://pixelscommander.com/wp-content/uploads/2014/12/P10.pd...

snazz 7y ago
Thank you for the link! I think that’s really helpful and those are good explanations for each rule. Does anyone know of a guide for writing C code where you allocate a specific block of memory at the start and then use that for all data from then on? Avoiding malloc is one of the suggestions there and seems like a smart strategy.
- baot 7y ago
  I've written code exactly like that and realised that it just kicks the can down the road: you're still allocating memory from a fixed block, it's just now the malloc is written by you, with more bugs, and you still need to deal with variable allocation delays and running out of memory. The real issue is if you don't know at compile-time what resources you'll need at run-time. For some problems that can be an intractable problem for making a safe product, including, to my knowledge, everything that runs on a rich OS.
  - carlmr 7y ago
    >The real issue is if you don't know at compile-time what resources you'll need at run-time. For some problems that can be an intractable problem for making a safe product, including, to my knowledge, everything that runs on a rich OS. You're right, but you should still constrain yourself to these few instances to use malloc instead of wildly using it everywhere.
- mypalmike 7y ago
  I've never seen a guide, but I worked on some console games around 15 years ago where the rule was "malloc is evil". That mindset was enlightening and felt "correct" compared to some of the sloppy memory management I'd seen (and, sadly, implemented) on some PC game titles I'd worked on before. Basically we treated the heap like a stack of large context oriented memory blocks. Each of these blocks contains fixed data loaded from disk (static game resources like bitmaps, UI layouts, etc) and fixed size pools of fixed size game objects. The big blocks would get allocated in a stacked manner at distinct times like game title load and level load. So if your game has bullets, you have a memory pool of say, 100 bullets to maintain the state of each instance. If you try to shoot a 101st bullet, you either don't or you have an ejection strategy. You never malloc or free during gameplay : you only allocate from one of the pools. When it's time to unload the level... boom, you free the whole block at once, popping this stack. This is extremely efficient compared to freeing many individual malloc allocations.
pjmlp 7y ago
And Frama-C as well. https://frama-c.com/ https://frama-c.com/ Also warnings as errors, alongside static analyzers.

snazz 7y ago

Thank you for the link! I think that’s really helpful and those are good explanations for each rule. Does anyone know of a guide for writing C code where you allocate a specific block of memory at the start and then use that for all data from then on? Avoiding malloc is one of the suggestions there and seems like a smart strategy.

baot 7y ago
I've written code exactly like that and realised that it just kicks the can down the road: you're still allocating memory from a fixed block, it's just now the malloc is written by you, with more bugs, and you still need to deal with variable allocation delays and running out of memory. The real issue is if you don't know at compile-time what resources you'll need at run-time. For some problems that can be an intractable problem for making a safe product, including, to my knowledge, everything that runs on a rich OS.
- carlmr 7y ago
  >The real issue is if you don't know at compile-time what resources you'll need at run-time. For some problems that can be an intractable problem for making a safe product, including, to my knowledge, everything that runs on a rich OS. You're right, but you should still constrain yourself to these few instances to use malloc instead of wildly using it everywhere.
mypalmike 7y ago
I've never seen a guide, but I worked on some console games around 15 years ago where the rule was "malloc is evil". That mindset was enlightening and felt "correct" compared to some of the sloppy memory management I'd seen (and, sadly, implemented) on some PC game titles I'd worked on before. Basically we treated the heap like a stack of large context oriented memory blocks. Each of these blocks contains fixed data loaded from disk (static game resources like bitmaps, UI layouts, etc) and fixed size pools of fixed size game objects. The big blocks would get allocated in a stacked manner at distinct times like game title load and level load. So if your game has bullets, you have a memory pool of say, 100 bullets to maintain the state of each instance. If you try to shoot a 101st bullet, you either don't or you have an ejection strategy. You never malloc or free during gameplay : you only allocate from one of the pools. When it's time to unload the level... boom, you free the whole block at once, popping this stack. This is extremely efficient compared to freeing many individual malloc allocations.

pjmlp 7y ago

And Frama-C as well. https://frama-c.com/ https://frama-c.com/ Also warnings as errors, alongside static analyzers.