C++调用系统调用时忽略返回值仅检查errno的方案是否有隐患？

方案核心逻辑 #

你提出的封装思路是：

• 封装函数开头将errno置为0
• 调用open/mmap/fstat等系统调用，忽略其返回值
• 通过自定义ko函数检查errno，非零则抛出std::runtime_error
• 依托errno的线程本地特性避免线程干扰

核心隐患 #

• errno与返回值的绑定关系被破坏：绝大多数POSIX系统调用仅在返回明确错误值（如-1、NULL）时，errno才有效。忽略返回值直接查errno，会把"之前残留的errno"或"成功场景下的意外修改"误判为当前调用错误。
• 错误场景的漏判：若某系统调用执行失败但未按标准设置errno（尽管不符合POSIX规范，但个别实现可能存在），ko函数会误判为成功，掩盖真实问题。
• 线程安全的极端风险：虽然errno是线程本地的，但如果系统调用后、检查errno前，线程触发了会修改errno的信号处理函数，会干扰判断结果。

errno意外非零的场景 #

• 历史残留值：若封装函数开头的errno=0操作被遗漏（比如代码分支跳过），当前线程之前的函数调用残留的errno会导致误判。
• 成功场景下的合法修改：部分函数在正常执行时也会设置errno，比如strtol转换成功但遇到非数字后缀时，会设置errno=EINVAL；部分特殊设备的read操作返回0（读到末尾）时，也可能附带设置errno。
• 信号中断干扰：系统调用被信号中断返回EINTR时，errno会被设置，但这种情况属于可恢复场景，直接抛出异常会中断正常流程。

关键注意事项 #

• 严格核对每个系统调用的man手册：必须明确：只有当函数返回特定错误值时，errno才有效；同时确认该函数成功执行时是否会修改errno。比如open仅在返回-1时设置errno，成功返回fd时不会修改；而部分字符串处理函数则有特殊行为。
• 绝对不能忽略系统调用的返回值：正确逻辑是先检查返回值是否为错误状态，再读取errno。比如open返回-1时，才触发ko函数检查errno并抛异常；忽略返回值会导致"成功调用却因历史errno抛异常"的乌龙。
• 处理可重启的错误：对EINTR这类可重启的错误，封装逻辑应自动重试调用，而非直接抛异常，避免不必要的中断。
• 保证检查流程的原子性：从设置errno=0到调用系统调用、检查errno的过程中，不能插入任何可能修改errno的函数（包括日志、内存分配等隐式调用）。
• 异常携带完整错误信息：抛出std::runtime_error时，要包含错误码和strerror(errno)生成的描述，方便定位问题。

内容的提问来源于stack exchange，提问作者ABu