MISRA C在谴责malloc + friends时出奇的简短。动态分配在所有与安全相关的应用中都是一个大忌,其他所有相关的标准也禁止它(IEC 61508+和其他“SIL”标准(火车,家用电器等),ISO 26262,DO 178,JSF和NASA标准等)。 由malloc返回的内存不足引起的潜在错误可能是该函数的最小问题-因为如果你的内存不足,这意味着你的整个程序设计都被破坏了,这不是malloc的错。 这篇Codidact文章详细回答了你的问题,包括嵌入式系统中malloc和动态分配的许多严重问题: Why should I not use dynamic memory allocation in embedded systems? 至于可以使用什么来代替,安全相关的应用程序使用静态大小的缓冲区。内存池在某些情况下也是可以接受的,只要你有错误检查/处理,看看我的答案here。
4条答案
按热度按时间q35jwt9p1#
任何呼叫都可能失败。如果没有内存分配,malloc将返回null。如果不检查此返回值,并为内存不足事件提供适当的处理逻辑,则程序可能会崩溃。通常,您唯一能做的就是向用户提供有关情况的消息。
如果你在一个安全关键的环境中,软件崩溃可能导致车祸,这是非常糟糕的,因此对于任何涉及汽车的真实的时间操作的循环,最好避免动态内存分配,因为这是潜在的递归。
以calloc的形式装点门面不会有任何区别。
bd1hkmkf2#
只是装门面吗?
确实是。使用
malloc
或calloc
(与malloc
+初始化相同)都没有关系。关键是检查返回值。
MISRA:
避免使用容易失败的函数和构造
脱离上下文,这使得想要进行动态内存分配的人别无选择,只能
1.不要理会MISRA的建议,只要确保每个分配都经过检查。
1.在程序启动时做一个大的静态分配,并将其用作整个程序中唯一的内存池。提供证据证明你的计划永远不会超过分配。
xytpbqjk3#
MISRA C的建议是:* 避免使用容易失败的函数和结构,例如,malloc可能会失败。* 我假设这意味着内存分配可能是一个问题,这是否意味着calloc是安全的?
MISRA C:2012(并持续到:2023)非常清楚:
如果这还不够:
<stdlib.h>
的内存分配和释放功能在规则21.3中,放大甚至列出了功能:
calloc
、malloc
、realloc
、aligned_alloc
和free
所以你的问题的简单答案是:不,
calloc
不可以如果您希望符合MISRA C。3hvapo4f4#
MISRA C在谴责malloc + friends时出奇的简短。动态分配在所有与安全相关的应用中都是一个大忌,其他所有相关的标准也禁止它(IEC 61508+和其他“SIL”标准(火车,家用电器等),ISO 26262,DO 178,JSF和NASA标准等)。
由
malloc
返回的内存不足引起的潜在错误可能是该函数的最小问题-因为如果你的内存不足,这意味着你的整个程序设计都被破坏了,这不是malloc的错。这篇Codidact文章详细回答了你的问题,包括嵌入式系统中malloc和动态分配的许多严重问题:
Why should I not use dynamic memory allocation in embedded systems?
至于可以使用什么来代替,安全相关的应用程序使用静态大小的缓冲区。内存池在某些情况下也是可以接受的,只要你有错误检查/处理,看看我的答案here。