C语言中如何查看函数的返回值？

Question

在C语言中，函数返回值本身不自动显示或打印，开发者常误以为“调用函数后值会自动可见”。典型问题：`int result = add(3, 5);` 执行后，若未显式输出（如 `printf("%d\n", result);`）或调试观察，便无法确认返回值是否符合预期；更隐蔽的是忽略返回值（如直接写 `add(3, 5);`），导致错误被掩盖。此外，对`void`函数取返回值、类型不匹配（如用`%d`打印指针返回值）、或未检查系统调用（如`fopen`返回`NULL`）等，均属高频隐患。尤其在嵌入式或系统编程中，忽略`errno`或`-1`类错误码极易引发崩溃。根本原因在于C语言无运行时反射机制，返回值仅存在于调用者的寄存器或栈帧中，必须主动捕获、存储并验证——这既是灵活性的来源，也是调试门槛所在。

Answer 1

一、现象层：函数调用“无声无息”——返回值的物理不可见性

C语言中，add(3, 5) 执行后，计算结果 不会自动输出、不写入标准流、不触发任何可观测副作用。它仅被存入调用约定指定的位置（如 x86-64 的 %rax 寄存器或栈顶），若上层未显式读取（int r = ...）、未参与后续表达式、未被调试器捕获，则该值在逻辑上“瞬时消亡”。这是C语言零抽象开销设计的直接体现，也是新手误判“函数已执行成功”的根源。

二、语法层：类型系统与返回值契约的刚性约束

• void func() 不得用于赋值或作为右值：int x = func(); → 编译错误（GCC/Clang 启用 -Wall 即报）
• 类型不匹配引发未定义行为（UB）：printf("%d", malloc(100)); 将指针高位截断为 int，输出不可预测值
• 隐式转换陷阱：size_t len = strlen(s); if (len < -1) 永假（因 size_t 无符号），但编译器未必警告

三、语义层：返回值承载控制流与错误状态双重语义

函数示例	正常返回含义	错误返回约定	配套检查机制
fopen()	非NULL文件指针	NULL	必须判空，否则 fread 崩溃
write()	实际写入字节数（≥0）	-1	需同步检查 errno（如 EAGAIN, ENOSPC）

四、工程层：高风险模式与防御性编程实践

以下代码片段揭示典型隐患及加固方案：

// ❌ 危险：忽略 fopen 返回值
FILE *fp = fopen("config.txt", "r");
fgets(buf, sizeof(buf), fp); // 若 fp==NULL，段错误！

// ✅ 防御：显式错误分支 + errno 上下文
FILE *fp = fopen("config.txt", "r");
if (!fp) {
    fprintf(stderr, "fopen failed: %s (errno=%d)\n", strerror(errno), errno);
    exit(EXIT_FAILURE);
}

五、调试层：从寄存器到符号化验证的可观测性构建

在嵌入式裸机开发中，无法依赖 printf，需结合硬件调试器观察返回值寄存器。例如 ARM Cortex-M3 调用 HAL_UART_Transmit() 后，立即检查 R0（返回值寄存器）是否为 HAL_OK（=0）。现代工具链可进一步通过 __attribute__((warn_unused_result)) 强制编译器对关键函数返回值进行使用检查：

__attribute__((warn_unused_result))
int safe_open(const char *path);
// 调用 safe_open() 而不检查返回值 → 编译警告

六、架构层：错误传播模型与分层校验策略

graph TD
    A[系统调用层] -->|write() 返回 -1| B[errno 设置]
    B --> C[库函数封装层]
    C -->|HAL_I2C_Master_Transmit 返回 HAL_ERROR| D[应用逻辑层]
    D --> E{是否启用严格模式？}
    E -->|是| F[触发断言/日志/看门狗复位]
    E -->|否| G[静默失败→隐蔽缺陷]

七、生态层：静态分析与编译器增强的协同防护

• Clang Static Analyzer 可检测 fopen 后未判空、malloc 未检查 NULL
• PC-lint Plus 支持自定义规则：标记所有未使用 [[nodiscard]] 函数的调用点
• 编译选项组合：-Wreturn-type -Wuninitialized -Wsign-compare -fno-omit-frame-pointer

八、认知层：重构开发者心智模型——从“执行即成功”到“契约即接口”

资深工程师应将每个函数视为一份双向契约： ▸ 调用者承诺：提供合法参数、检查返回值、处理 errno； ▸ 被调用者承诺：按文档约定返回状态、不隐式修改全局变量、错误路径资源清理完备。 这种契约思维是跨越 Linux 系统编程、RTOS 驱动开发、安全关键嵌入式系统的通用底层能力。

九、演进层：C23 标准对返回值安全的增强支持

C23 引入 [[nodiscard]]（已由 C17 部分编译器支持）和更严格的 const 限定符，允许声明：

[[nodiscard("check return code")]]
ssize_t sendto(int sockfd, const void *buf, size_t len,
               int flags, const struct sockaddr *dest_addr,
               socklen_t addrlen);

当调用者忽略该返回值时，GCC 12+ / Clang 14+ 将生成带上下文提示的警告，显著提升错误可见性。

十、实战层：一套可落地的团队级返回值治理规范

1. 所有 I/O、内存分配、系统调用函数必须用 [[nodiscard]] 标记
2. CI 流水线强制启用 -Werror=unused-result
3. 代码审查 checklist 第一条：“是否存在未检查的 fopen/malloc/ioctl 返回值？”
4. 嵌入式项目启用 __assert_fail 替代裸 while(1)，并在 assert 中打印返回值与 errno
5. 建立 return_code.h 统一错误码枚举与字符串映射表，支持运行时诊断