wolfSSL（一个面向嵌入式和 IoT 的 C 语言 TLS/加密库）发布了 wolfCOSE（一个面向嵌入式设备的 COSE 实现），主打 zero alloc 和较小 RAM 占用。COSE 是 IETF 的对象签名与加密标准，常与 JOSE（JSON 体系里的签名/加密标准）对照理解，而 CBOR（Binary JSON 风格的数据格式）则是它的底层编码。评论区没有主要在争“这个标准是什么”，而是在抠产品文案里的内存表述：zero alloc 究竟是只是不用 malloc，还是也应该尽量避免大栈帧。有人还质疑 README 中的 .text、.bss、.data 和“约 <1KB RAM”这类数字如果不说明架构、编译器和 flags，就很难直接比较。
有评论先把 COSE 解释清楚：它是 CBOR Object Signing and Encryption，建立在 CBOR 这种二进制 JSON 替代格式之上。也有人指出它的设计思路很像 JOSE 这一套 JSON 签名/加密标准，JWK 也属于同一体系。对于不熟悉协议的人来说，这让 wolfCOSE 的定位更像是把 JSON 世界里的签名与加密能力，迁移到更适合受限设备的 CBOR 生态里。还有人顺手把它类比成 JWT 的替代品，说明讨论者主要是在对照现有 Web 生态理解它。
争论的核心是“zero alloc”应不应该理解为“零 malloc”，而不是“完全不占栈”。支持者认为，只要没有 heap allocation，且由调用方提供 buffer，就可以合理地称为 zero dynamic allocation。反对者则提醒，README 里写的 0 .bss 和 0 .data 并不自动等于资源占用极小，很多内存其实可能被挪到别处，尤其是栈。双方其实不是在否认同一事实，而是在争论宣传语是否足够准确、是否容易让人误解成“几乎不占任何内存”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
更偏嵌入式实践的评论强调，真正的风险不是“有没有 malloc”，而是局部数组和调用深度会不会把栈吃光。有人以 2KB RAM 的 8-bit MCU 为例，指出在这种环境里，几个几十到几百字节的栈开销都可能导致溢出，而且很多设备没有硬件栈保护，后果就是静默破坏数据。另有评论认为，严格意义上的 zero alloc 应该还能保证最大栈使用可静态分析，不能出现 recursion、function pointers、VLA 或 alloca 这类让峰值难以证明的东西。还有人补充说，只看 .text、.bss、.data 的数字没什么意义，必须结合架构、编译器和编译选项一起看。
COSE: CBOR Object Signing and Encryption，用 CBOR 承载签名与加密对象的标准。
CBOR: 一种二进制数据编码格式，可视为更适合机器和受限设备的 JSON 替代方案。
JOSE: JSON Object Signing and Encryption 规范家族，COSE 的设计常被认为与它对照。
zero dynamic allocation: 运行时不向 heap 申请内存，通常依赖调用方预先提供 buffer。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。