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。