Boost Process被终止进程的退出码取值及不同版本返回差异问题

首先明确：不存在所有平台通用的唯一合法返回码，返回值的合法性完全绑定当前操作系统的进程状态约定：

• POSIX体系（Linux、macOS等）：进程被信号主动终止时，合法的可观测返回值满足128 + 终止信号编号的规则（因为正常进程的有效退出码范围是0~127），比如被SIGKILL（编号9）终止的进程，返回码为137，被SIGTERM（编号15）终止的进程返回码为143。
• Windows体系：没有信号机制，进程被TerminateProcess接口主动终止时，返回码由终止操作的调用方自定义，只要符合32位整数的取值范围即为合法，没有强制统一的固定值。

Boost.Process 版本返回码差异的实现原因 #

对应上述复现场景，两个版本的返回值都不完全符合平台原生约定，差异来自库本身的实现逻辑变更：

复现场景：启动运行bash -c "while true; do true; done"的子进程，通过Boost.Process的child类terminate方法终止子进程，跨版本测试结果：

• Boost 1.65版本：被终止进程返回码为0
• Boost 1.71版本：相同操作下进程返回码为383

• Boost 1.65的返回值属于实现缺陷：该版本的terminate方法没有正确捕获子进程被终止后的状态，而是默认读取了进程启动时初始化的0值作为返回码，完全没有反映“进程被主动终止”的实际状态，不属于合法的业务场景返回值。
• Boost 1.71的返回值属于库自定义的终止标记：该版本重构了退出状态解析逻辑，没有完全对齐各平台的原生退出状态规则，而是将主动终止的场景设置为自定义值383作为内部标记，用来区分进程是正常退出还是被库主动终止的。

实践注意：使用Boost.Process的terminate接口时，不要依赖固定的返回值判断进程是否被主动终止，应该通过库提供的退出状态判断接口（而非直接读取原始返回值）来区分退出原因，避免跨版本的兼容问题。

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