每个参考页上的 ERRORS 部分指定了哪个错误 所有实现都应检测到条件（“将失败”） 并且可以由实现可选地检测到（“可能 失败”）。如果没有检测到错误条件，则请求的操作应 成功的。如果检测到错误情况，则请求的操作 除非另有说明，否则可能已部分执行。
实现可能会生成此处列出的错误编号 上述情况以外的情况，当且仅当所有这些情况 错误条件总是可以与错误一样对待 本卷 POSIX.1-2017 中描述的条件。 实现不应生成与一个不同的错误号 本卷 POSIX.1-2017 要求的错误条件 在本卷 POSIX.1-2017 中进行了描述，但可能会产生额外的 除非明确禁止特定功能出现错误。
我是从posix spec 找到的。我不是很擅长英语，所以我不确定我是否正确理解了它们，但据我所知，它说实现可以生成错误编号，这些错误编号未在每个函数参考页面的 ERRORS 部分中指定。那么为什么在任何情况下都可以“可能失败”时在 ERRORS 部分指定“可能失败”的情况？
【问题讨论】：
那么为什么在任何情况下都可能“可能失败”时在 ERRORS 部分指定“可能失败”的情况？
因为这些情况
在实践中，“将失败”和“可能失败”两种情况的组合涵盖了观察到的绝大多数失败。允许出现额外错误的函数是实现的安全阀。
【讨论】：
它提供了一个记录在什么情况下可能使用这些错误代码的机会，并规定在记录的情况下使用哪些代码。
让我们看看同一出版物中的open。
如果“路径名的组件长度超过 {NAME_MAX}”，它会说 open 必须以 ENAMETOOLONG 失败。但是您刚刚收到错误消息，并且您知道路径名的任何组成部分都不长于 {NAME_MAX}。
好吧，规范还说，如果“路径名的长度超过 {PATH_MAX}，或者符号链接的路径名解析产生长度超过 {PATH_MAX} 的中间结果，它可能会失败 ENAMETOOLONG .”这可以帮助您意识到这不是您的路径问题，而是您正在访问的符号链接的问题。
列出“可能失败”让我们在开始“猜测”之前有更多需要检查的地方。
从不同的方向来看我们的示例，我们不希望 POSIX 的一个实现者为太长的符号链接返回 ENAMETOOLONG，而另一个实现者返回不同的错误。
记录“可能失败”的情况会锁定实施者在该错误条件下始终返回ENAMETOOLONG。
【讨论】：