谁应为程序启动时打开三个标准流负责？自研OS内核疑问

核心结论 #

• 内核无需也不应为用户进程默认初始化0、1、2号标准流描述符，这是用户态（尤其是shell）遵循的POSIX惯例，而非内核强制逻辑。
• C库启动代码（如crt.c）不负责创建这些文件描述符，仅负责将已存在的0/1/2描述符封装为stdin/stdout/stderr结构体。

关键细节拆解 #

1. fork()与execve()的继承逻辑
   这两个系统调用会完整保留父进程已打开的文件描述符。shell启动新进程时，会先确保自身的0/1/2已关联到终端（或重定向目标），再通过fork()将这些描述符继承给子进程，最后execve()加载目标程序——全程内核仅被动保留描述符，未主动创建标准流。

2. APUE描述的本质

   按照惯例，UNIX系统shell将文件描述符0关联到进程的标准输入，1关联到标准输出，2关联到标准错误。这一惯例被shell及诸多应用遵循，但并非UNIX内核的特性。
   这段表述的核心是：标准流的关联是用户态行为约定，内核不做强制要求。若进程启动时0/1/2未被打开，仍可正常运行（仅读写这些描述符会报错）；POSIX仅规定，若进程使用标准流，必须对应0/1/2这三个编号。

3. C库的职责边界
   C库启动代码会在进入main()前，检查0/1/2是否已打开，再封装为stdin/stdout/stderr。但它不会主动打开设备文件（如/dev/tty）来初始化这些描述符——如果0/1/2未被预先打开，C库的标准流操作会直接返回错误。

极端场景验证 #

若跳过shell，直接在内核中启动用户进程且未打开任何文件描述符，该进程的0/1/2会处于未分配状态，此时调用printf()这类C库函数会失败，因为stdout对应的文件描述符无效。只有用户态程序自行打开设备/文件，并将描述符设置为0/1/2，才能符合标准流惯例。

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