4 ms·

> Very common, and you can't ever mess up freeing memory. Except that where misra is applied, there often is no dynamic allocation at all.

RealityVoid 3y ago
Most of the times, not always. They sometimes don't use malloc or free but their own special little memory pools.
- BeetleB 3y ago
  From my experience in automotive, the ISO standard is against dynamic allocation if your system is classified high enough in terms of their safety levels. As an example, we weren't allowed to use the C++ string class, and had to find a "safer" string class for C++. (Not sure about MISRA - most of my experience is with the ISO standard, and MISRA is not mandated by it).
  - RealityVoid 3y ago
    Yeah, so what they do is they don't use free and malloc, but use a bunch of buffers they free. Tadaa! We don't have dynamic allocation, just buffers, see? I've seen it, I can count in AUTOSAR systems like... 20 different hand spun allocators, 10 ques and 50 special little hierarchical state machines.
  - DaiPlusPlus 3y ago
    Forgive my lack of exposure to safety-critical C, but without dynamic allocation how does a program handle large state with indeterminate lifetimes? Or when you need a temporary buffer that’s too big to live on the stack?
    - RealityVoid 3y ago
      You make the stack bigger. You might think I'm joking, but I'm not. Or you make it static. You can work around it just fine.
    - BeetleB 3y ago
      > but without dynamic allocation how does a program handle large state with indeterminate lifetimes? If you haven't, I strongly encourage taking a workshop/course on requirements engineering (not specific to SW nor safety). One thing that stood out is a requirement that says things like "indeterminate" or "large" are red flags. A requirement should state bounds on what sizes it should handle. > Or when you need a temporary buffer that’s too big to live on the stack? Do you have an example of where this may occur in a safety critical system? I've forgotten the details, but many/most forbidden things are allowed in the code provided you have watchdogs for mitigation - so if things did fail it could safely shut down. I don't recall if dynamic allocation fell into that category.
    - rurban 3y ago
      large state is too complicated and error prone. cut it down. don't put big temp. buffers onto the stack, put them into your .data segment. (i.e. global).

RealityVoid 3y ago

Most of the times, not always. They sometimes don't use malloc or free but their own special little memory pools.

BeetleB 3y ago
From my experience in automotive, the ISO standard is against dynamic allocation if your system is classified high enough in terms of their safety levels. As an example, we weren't allowed to use the C++ string class, and had to find a "safer" string class for C++. (Not sure about MISRA - most of my experience is with the ISO standard, and MISRA is not mandated by it).
- RealityVoid 3y ago
  Yeah, so what they do is they don't use free and malloc, but use a bunch of buffers they free. Tadaa! We don't have dynamic allocation, just buffers, see? I've seen it, I can count in AUTOSAR systems like... 20 different hand spun allocators, 10 ques and 50 special little hierarchical state machines.
- DaiPlusPlus 3y ago
  Forgive my lack of exposure to safety-critical C, but without dynamic allocation how does a program handle large state with indeterminate lifetimes? Or when you need a temporary buffer that’s too big to live on the stack?
  - RealityVoid 3y ago
    You make the stack bigger. You might think I'm joking, but I'm not. Or you make it static. You can work around it just fine.
  - BeetleB 3y ago
    > but without dynamic allocation how does a program handle large state with indeterminate lifetimes? If you haven't, I strongly encourage taking a workshop/course on requirements engineering (not specific to SW nor safety). One thing that stood out is a requirement that says things like "indeterminate" or "large" are red flags. A requirement should state bounds on what sizes it should handle. > Or when you need a temporary buffer that’s too big to live on the stack? Do you have an example of where this may occur in a safety critical system? I've forgotten the details, but many/most forbidden things are allowed in the code provided you have watchdogs for mitigation - so if things did fail it could safely shut down. I don't recall if dynamic allocation fell into that category.
  - rurban 3y ago
    large state is too complicated and error prone. cut it down. don't put big temp. buffers onto the stack, put them into your .data segment. (i.e. global).