fstat(2)与fstat(3)为何同时存在？该如何选择使用？

为什么fstat同时存在系统调用和C标准函数版本？ #

类Unix系统采用分层设计：内核提供**fstat(2)这类底层系统调用，作为直接访问文件系统的入口；而C标准库的fstat(3)**则是对系统调用的封装，提供符合C/POSIX标准的抽象接口。

这种分层的核心原因：

• 标准化统一：系统调用是平台特有的，不同Unix-like系统（如Linux、FreeBSD）的实现细节可能有差异；标准库函数则遵循通用标准，抹平平台差异，让代码更易移植。
• 额外逻辑封装：标准库会处理参数校验、错误码标准化（把内核返回的底层错误映射到标准errno）、甚至用户态缓存优化，而系统调用只执行最底层操作，不做额外处理。
• 版本兼容：标准库可以在不同内核版本间做兼容适配，比如旧内核不支持的字段，会自动填充默认值，保证代码跨版本运行。

fstat(3P)是严格遵循POSIX标准的版本，属于标准库范畴，相比部分平台特有的fstat(3)，它不含非标准扩展。

fstat(2)与fstat(3)的使用优势对比 #

fstat(3)的优势 #

• 无需手动声明原型：包含标准头文件<sys/stat.h>即可获取函数原型，避免手动声明的错误。
• 跨平台性强：遵循C/POSIX标准，所有符合标准的系统（包括类Unix和Windows的兼容实现）都提供一致接口，移植成本低。
• 错误处理更友好：自动将内核底层错误转换为标准errno语义，简化错误处理逻辑。
• 附加功能支持：部分实现提供线程安全封装或用户态缓存，提升常规场景下的性能。

fstat(2)的优势 #

• 无额外开销：直接调用内核，跳过标准库的封装逻辑，适合性能极端敏感的场景。
• 访问平台特有扩展：可以直接使用内核提供的非标准字段（比如Linuxstruct stat中的高精度时间字段st_atime_nsec）。
• 精确控制底层行为：避免标准库的缓存机制，确保获取的是内核实时的文件状态，适合需要精确控制的场景。

C语言如何区分调用的是fstat(2)还是fstat(3)？ #

默认情况下，fstat(fd, &buf)调用的是fstat(3)：

• 标准头文件<sys/stat.h>中声明的是标准库的fstat(3)原型。
• 链接阶段，编译器会自动链接标准库，优先使用标准库的实现。

要调用fstat(2)，通常采用两种方式：

1. 通过syscall()直接调用（Linux下）：

   #include <sys/syscall.h>
   #include <sys/stat.h>
   
   int result = syscall(SYS_fstat, fd, &buf);
   

2. 手动声明原型：部分平台可通过定义特定宏（如Linux的_GNU_SOURCE）暴露系统调用原型，但兼容性差；更可靠的是自行声明原型，但需注意struct stat的定义可能与标准库版本有差异，需使用内核对应的结构体。

跨平台场景的选择 #

优先选择fstat(3)（或fstat(3P)）：

• 它遵循通用标准，所有符合C/POSIX的类Unix系统都提供一致接口。
• Windows虽无类Unix系统调用，但C运行时库提供了兼容的_fstat实现，只需少量修改即可适配。
• fstat(2)是平台特有的系统调用，不同内核的接口细节（如struct stat字段、返回值）差异大，移植成本极高。

Windows平台的特殊说明 #

Windows没有类Unix的“系统调用层级”概念，文件操作依赖Win32 API和C运行时库封装。官方示例中的_fstat属于C标准库范畴，对应类Unix的fstat(3)，因此无需手动声明原型——包含<sys/stat.h>或<stdio.h>即可获取标准原型。

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