https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:59 +0000 MyBB https://forum.misra.org.uk/showthread.php?tid=1482 Mon, 25 Mar 2019 18:38:26 +0000 Sebastien.Ashby@nxp]]> https://forum.misra.org.uk/showthread.php?tid=1482
I have a question about Rule 18-4-1 "Dynamic heap memory allocation shall not be used.".

C++ already has a form of memory allocation for its automatic variables.
That is they are allocated on the stack.
I take for granted that this form of memory allocation is allowed by MISRA.

Would managing and allocating the heap space in a stack fashion address most concerns associated with rule 18-4-1?

For example, the call stack is also subject to out-of-storage runtime failure, i.e. stack overflow.
The call stack being used to store a host of values associated with function calls and its depth may be based on runtime values.
The only way to secure against this being to find the worst case your system allows and set the stack size accordingly.

If the heap space allocator was not subject to:

• Memory leaks
  Non-deterministic behavior
  • Fragmentation
    Order of allocation/deallocation
    

And the memory exhaustion case was handled in the same fashion as the call stack.
Meaning testing your system to find the worst case and ensuring that at least that amount is available.

Would this type of dynamic heap memory allocation be compliant with the intent of rule 18-4-1?


Best regards.

Sebastien Ashby]]>
I have a question about Rule 18-4-1 "Dynamic heap memory allocation shall not be used.".

C++ already has a form of memory allocation for its automatic variables.
That is they are allocated on the stack.
I take for granted that this form of memory allocation is allowed by MISRA.

Would managing and allocating the heap space in a stack fashion address most concerns associated with rule 18-4-1?

For example, the call stack is also subject to out-of-storage runtime failure, i.e. stack overflow.
The call stack being used to store a host of values associated with function calls and its depth may be based on runtime values.
The only way to secure against this being to find the worst case your system allows and set the stack size accordingly.

If the heap space allocator was not subject to:

• Memory leaks
  Non-deterministic behavior
  • Fragmentation
    Order of allocation/deallocation
    

And the memory exhaustion case was handled in the same fashion as the call stack.
Meaning testing your system to find the worst case and ensuring that at least that amount is available.

Would this type of dynamic heap memory allocation be compliant with the intent of rule 18-4-1?


Best regards.

Sebastien Ashby]]> https://forum.misra.org.uk/showthread.php?tid=1338 Wed, 19 Apr 2017 10:47:18 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1338 The heading of the rule uses the generic term functions while the body of the rule explicitly lists all string functions -> confusing!
So, since memcpy is declared in the heading would fit here, while the body does not.
Nevertheless, since memcpy_s etc. is not available in C99/C++03 i think a deviation with reason "code quality/portability" would be justified.
Do you agree?]]> The heading of the rule uses the generic term functions while the body of the rule explicitly lists all string functions -> confusing!
So, since memcpy is declared in the heading would fit here, while the body does not.
Nevertheless, since memcpy_s etc. is not available in C99/C++03 i think a deviation with reason "code quality/portability" would be justified.
Do you agree?]]> https://forum.misra.org.uk/showthread.php?tid=1274 Wed, 21 Sep 2016 12:27:38 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1274
i recently stumbled upon Rule 21.9 of MISRA C 2012 which prohibits use of bsearch/qsort.
Currently, there is no equivalent in MISRA C++ 2008, so it would be legal to use bsearch/qsort in C++ (if you use cstdlib that is).
Maybe this is another synchronization topic for the next version of the standard (along with the preprocessor usage, see https://misra.org.uk/forum/viewtopic.php...1549#p3031).
Thanks.]]>
i recently stumbled upon Rule 21.9 of MISRA C 2012 which prohibits use of bsearch/qsort.
Currently, there is no equivalent in MISRA C++ 2008, so it would be legal to use bsearch/qsort in C++ (if you use cstdlib that is).
Maybe this is another synchronization topic for the next version of the standard (along with the preprocessor usage, see https://misra.org.uk/forum/viewtopic.php...1549#p3031).
Thanks.]]> https://forum.misra.org.uk/showthread.php?tid=586 Mon, 29 Sep 2008 09:28:54 +0000 shanz]]> https://forum.misra.org.uk/showthread.php?tid=586 C++ often relies on dynamically allocated pointers to achieve (run-time) polymorphism.

How can polymorphism be achieved without resorting to dynamic memory allocation?
I suspect that preallocating pointers on the stack is the answer but can someone please write some example code?

Thanks.]]> C++ often relies on dynamically allocated pointers to achieve (run-time) polymorphism.

How can polymorphism be achieved without resorting to dynamic memory allocation?
I suspect that preallocating pointers on the stack is the answer but can someone please write some example code?

Thanks.]]> https://forum.misra.org.uk/showthread.php?tid=580 Thu, 11 Sep 2008 13:03:41 +0000 nakagawat]]> https://forum.misra.org.uk/showthread.php?tid=580 C libraries entirely. At the same time, the 'Rationale' section of this
rule admits the use of the C++ libraries which correspond to C libraries.

Many of the C++ libraries corresponding to C libraries are defined
as the C libraries surrounded by the std namespace. For the reason,
we think even if the C++ libraries corresponding to C libraries
are used, it is impossible to avoid such vulnerability C libraries
have as undefined behavior and unspecified behavior.

Why does the Rule 18-0-1 admit the use of the C++ libraries corresponding
to C libraries?]]> C libraries entirely. At the same time, the 'Rationale' section of this
rule admits the use of the C++ libraries which correspond to C libraries.

Many of the C++ libraries corresponding to C libraries are defined
as the C libraries surrounded by the std namespace. For the reason,
we think even if the C++ libraries corresponding to C libraries
are used, it is impossible to avoid such vulnerability C libraries
have as undefined behavior and unspecified behavior.

Why does the Rule 18-0-1 admit the use of the C++ libraries corresponding
to C libraries?]]>