嵌入式高手都在偷偷用的“第23条”：用 warn_unused_result 让每个返回值都被“签收”——编译器帮你堵住遗漏的错误检查
该文章同步至OneChan
你有没有遇到过：调用了
malloc却忘了判空，写了个返回错误码的函数，调用者却潇洒地忽略，最后系统在客户手里崩溃，查半天才发现是一个没被检查的返回值？
大家好，我是你们的老朋友。
这是资深工程师压箱底的编程技巧系列第二十三篇。前面我们学会了用format属性让编译器检查日志格式，用hot/cold优化代码布局，用noreturn消除死代码。今天这一招，直接封堵另一类极其常见的人为疏忽——调用者忘记检查函数的返回值。
它就是 GCC/Clang 中一个能彻底改变团队编码习惯的属性：
__attribute__((warn_unused_result))。
这个属性告诉编译器：“我的返回值很重要，调用者必须处理它。如果谁敢不接收、不判断，就给我报警告。” 对于任何可能出错的操作——内存分配、外设初始化、消息发送、加锁——这都是一道免死金牌。
一、这东西到底是干什么用的？
简单说：warn_unused_result标记一个函数，其返回值不能被忽略。如果调用者不把返回值赋给一个变量，或者不在表达式中显式使用它，编译器就生成一个警告，提醒程序员“你可能遗漏了重要的检查”。
它的声明：
intcritical_operation(void)__attribute__((warn_unused_result));调用时如果写：
critical_operation();// 返回值被忽略编译器会输出类似：
warning: ignoring return value of 'critical_operation', declared with attribute 'warn_unused_result'这本质上是一种“强制注意力机制”。大多数情况下，返回值里包含着成功/失败状态、分配的内存指针、读取的数据长度等关键信息。忽略它们可能导致：
- 内存泄漏（
malloc返回NULL后继续使用） - 死锁（
mutex_trylock失败后仍访问共享资源） - 数据丢失（
UART_Send返回未发送完毕的字节数却不处理） - 逻辑错误（
ADC_Read返回错误码却被当作有效值）
人类会疲劳、会粗心，编译器不会。把“检查返回值”写进编译规则，比写进任何编码规范都管用。
二、上硬菜，直接看怎么用
Step 1：标记一个容易出错的函数
假设你有一个函数用于发送 CAN 消息，它返回实际发送的字节数。如果 FIFO 满了，可能返回 0，调用者必须处理这种情况。
// can.hintCAN_Send(uint32_tid,uint8_t*data,uint8_tlen)__attribute__((warn_unused_result));// can.cintCAN_Send(uint32_tid,uint8_t*data,uint8_tlen){if(CAN_FIFO_FULL)return0;// 实际发送returnlen;}现在，任何调用CAN_Send的代码如果不接收返回值，编译时就会收到警告：
CAN_Send(0x123,buffer,8);// 警告：返回值未使用强迫调用者必须写：
intsent=CAN_Send(0x123,buffer,8);if(sent!=8){// 处理发送失败}如果调用者确实非常确定不需要检查（极其罕见），也必须显式地抛弃返回值，例如(void)CAN_Send(...);。这个(void)是一种向编译器“签核”的行为，明确告知“我知道返回值被忽略了，我负责”。它让代码审查时一眼就能看到这种危险操作。
Step 2：搭配标准库函数
许多标准库函数在 GCC 中已经被内部标记了这个属性。比如realloc、scanf等。你可以在自己的代码中重新声明这些函数并加上属性，以覆盖默认行为吗？通常不需要，因为标准头文件已经处理好了，但你可以在自己的封装上使用。
例如，封装一个内存分配器：
void*my_malloc(size_tsize)__attribute__((warn_unused_result,malloc));void*my_malloc(size_tsize){// 实现内存分配，返回 NULL 表示失败returnpvPortMalloc(size);}这样任何调用my_malloc(1024)却忘记判空的地方都会被揪出来。
Step 3：应用于枚举返回值——让错误码必须被检查
很多底层驱动返回枚举类型表示状态：
typedefenum{DRV_OK,DRV_TIMEOUT,DRV_CRC_ERROR,DRV_BUSY}drv_status_t;drv_status_tI2C_Read(uint8_taddr,uint8_t*buf,uint16_tlen)__attribute__((warn_unused_result));如果有人写：
I2C_Read(0x50,data,4);// 直接使用 data，不检查返回值编译器就会发出警告。这让那些“沉默失败”的外设操作必须被上层知道，极大提升系统的可见性。
三、举一反三，warn_unused_result的进阶玩法
1. 把它设计成项目默认规则
你可以通过编译器选项-Werror=unused-result将这类警告升级为错误。这意味着，所有忘记检查返回值的情况直接编译失败。这在安全关键系统（如医疗设备、汽车控制器）中已经是标准实践。
2. 与__attribute__((error))联动
如果一个函数不仅不能忽略返回值，甚至根本不应该被调用（除非在特殊上下文中），你可以先用warn_unused_result给出警告，再用error属性在特定条件下阻止调用。例如，一个只能由中断内部调用的函数，可以在发布版本中用宏和error配合。
3. 在 C++ 中使用[[nodiscard]]
如果你在嵌入式环境中使用 C++（如 Arduino、PlatformIO），C++17 引入了标准属性[[nodiscard]]，功能与warn_unused_result相同。但 C 语言没有这个标准属性，所以__attribute__仍是主力。
4. 小心过度使用
不是每个函数都需要这个属性。如果一个返回值纯粹是“方便”性质的，比如返回void本来就没有返回值，或者返回值只是链式调用用的（如return *this风格），加上它只会让代码充满(void)强转，降低可读性。一般只对可能出错、返回错误信息、分配资源的函数使用。
四、留两个问题给你思考
请你停下来，思考这两个实际问题：
- 如果一个函数被标记为
warn_unused_result，但调用者确实不关心返回值（比如调用一个“可能失败但不影响主流程”的日志函数），除了用(void)强转，还有没有更优雅的做法？ - 当函数返回值是一个结构体（比如一个包含指针和错误码的复合结构），
warn_unused_result还能正常工作吗？如果调用者只访问结构体的某个成员而忽略了整体，编译器会报警吗？
想清楚这两个问题，你就能在团队里自如地制定“返回值必须被检查”的规则，而不被同事抱怨。
五、总结与思考题回答
核心总结：
__attribute__((warn_unused_result))强制调用者必须显式接收或使用返回值，否则编译警告。- 核心用途：错误状态函数、内存分配、外设操作、数据发送/接收等任何可能失败的操作。
- 优势：将“检查返回值”从人工纪律变为编译器强制，配合
-Werror可彻底杜绝疏忽。 - 注意事项：不适用于无害返回值函数；调用者可用
(void)显式忽略，但应视为谨慎操作。
思考题回答
问题1：除了(void)强转，还有没有更优雅的做法？
最直接的方式就是(void)function();，它清晰地向编译器和代码审查者表明“我知道返回值被抛弃了”。其他方式：
- 如果你确实需要一个“可能失败但允许忽略”的版本，可以提供一个包装函数，该函数内部调用主函数并显式忽略返回值，且不标记
warn_unused_result。例如void log_try(const char *msg) { (void)log_write(msg); }。这样调用者可以使用log_try，而需要检查返回值时用log_write。 - 另一种思路是改变设计：如果调用者经常需要忽略错误，也许函数本身的错误不应该通过返回值表达，而是通过其他方式（如设置全局错误码、触发错误处理回调）。这样函数的返回值可以变成
void，自然就不需要属性了。
问题2：返回结构体时属性如何工作？
如果函数返回一个结构体，warn_unused_result要求整个结构体必须被使用。如果调用者只是func().member;这样访问成员，因为整个返回值并没有被赋值给一个变量，编译器可能认为返回值未被使用，从而发出警告。具体行为取决于编译器：GCC 会检查返回值是否作为整体被读取。如果你只关心某个成员，应该先接收整体：MyStruct s = func(); if (s.member) ...。这确保了错误码或其他信息不会被无意间丢弃。所以属性对结构体同样有效，能防止调用者只取成员而忽略其他重要字段。
好了，第 23 招我们就彻底吃透了。下次定义关键接口时，别忘了加上这个属性，让你的 API 自己会“要求”调用者好好检查返回值。
如果今天的内容让你对 API 设计有了新的认识，欢迎转发和点赞。下一篇我们继续挖：用__attribute__((fallthrough))明确switch中的故意穿透。咱们不见不散！