C 退出状态是可观察的行为吗？

C 2018第5.1.2.3 6条规定：

一致性实施的最低要求是：

• 对易失性对象的访问严格按照抽象机器的规则进行评估

• 在程序终止时，写入文件的所有数据应与根据抽象语义执行程序所产生的结果相同

• 交互设备的输入和输出动态应按照7.21.3的规定进行。这些要求的目的是尽快出现无缓冲或行缓冲输出，以确保提示消息在程序等待输入之前出现

这是程序的可观察行为

表面上看，这不包括程序的退出状态

关于退出（状态），7.22.4.4.5说：

最后，将控件返回到主机环境。如果

status

的值为零或

EXIT\u SUCCESS

，则返回状态成功终止的实现定义形式。如果

status

的值为

EXIT\u FAILURE

，则返回状态unsuccessful termination的实现定义形式。否则，返回的状态是实现定义的

---

标准没有告诉我们这是可观察行为的一部分。当然，这种

exit

行为纯粹是对C的抽象机器的描述是没有意义的；将值返回到环境中没有意义，除非它在环境中可见。因此，我的问题不在于退出状态是否可观察，而在于这是否是C标准对可观察行为定义中的缺陷。或者标准中是否有其他适用的文本？

退出状态应该是运行实现的主机环境可以观察到的。主机环境是否对此进行了任何处理都超出了标准的范围。

我认为可以将其拼凑起来，看看答案是否符合§5.1.2.3.6的第一个要点：

对易失性对象的访问严格按照 抽象机器的规则

进一步看，§3.1将“访问”定义为：

读取或修改对象的值

§3.15将“对象”定义为：

执行环境中的数据存储区域 哪些可以表示值

奇怪的是，该标准没有包含“易失性对象”的定义。它确实包含§6.7.3.6中“具有挥发性限定类型的对象”的定义：

具有volatile限定类型的对象可以通过以下方式进行修改 实施未知或有其他未知的副作用。 因此，提及此类对象的任何表述应为： 严格按照抽象机器的规则进行评估，如 如5.1.2.3所述

推断一个具有volatile限定类型的对象具有该限定类型似乎是不合理的，因为它可以准确地通知编译器它实际上是一个volatile对象，所以我不认为使用此措辞作为“volatile对象”本身定义的基础太过分了，以及将易失性对象定义为可以以实现未知的方式修改或具有其他未知副作用的对象

§5.1.2.3.2对“副作用”的定义如下：

访问易失性对象、修改对象、修改文件或 调用执行任何这些操作的函数都是片面的 效果，即执行环境状态的更改

因此，我认为我们可以将其组合如下：

返回要返回到主机环境的退出状态为 显然，执行环境的状态发生了变化，如 例如，接收后的执行环境，

EXIT\u SUCCESS

，必须处于不同的状态 例如，如果它接收到退出失败。返回出口 因此，根据§5.1.2.3.2，状态是一种副作用

exit（）

是执行此操作的函数，因此调用

exit（）

是非常困难的 本身也是§5.1.2.3.2规定的副作用

该标准显然没有给我们详细的内部工作原理

exit（）
主机环境，但假设访问
不会涉及对象，因为对象是数据区域
执行环境中的存储，其内容可以表示
值，退出状态是一个值

因为我们不知道主机环境会做什么 作为对状态变化的响应（尤其是因为我们的程序 将在发生之前退出），此访问有未知的一面 因此，访问的对象是一个易失性对象

由于调用

exit（）

会访问易失性对象，因此它是可观察的 符合§5.1.2.3.6的行为

这与对具有易变限定类型的对象的正常理解是一致的，也就是说，如果我们不能确定没有必要的副作用将被忽略，我们就无法优化对此类对象的访问，因为如果我们这样做，可观察的行为（在正常的日常意义上）可能会受到影响。当然，在这种情况下，不存在volatile限定类型的可见对象，因为volatile对象是由

exit（）

在内部访问的，而且

exit（）

显然甚至不需要用C编写。但毫无疑问，似乎存在一个volatile对象，§5.1.2.3特别提及（三次）到易失性对象，而不是易失性限定类型的对象（以及除fo以外的对象