为什么 posix 规范中有 'may fail' 个案例？
Why are there 'may fail' cases in posix spec?
The ERRORS section on each reference page specifies which error
conditions shall be detected by all implementations ("shall fail")
and which may be optionally detected by an implementation ("may
fail"). If no error condition is detected, the action requested shall
be successful. If an error condition is detected, the action requested
may have been partially performed, unless otherwise stated.
Implementations may generate error numbers listed here under
circumstances other than those described, if and only if all those
error conditions can always be treated identically to the error
conditions as described in this volume of POSIX.1-2017.
Implementations shall not generate a different error number from one
required by this volume of POSIX.1-2017 for an error condition
described in this volume of POSIX.1-2017, but may generate additional
errors unless explicitly disallowed for a particular function.
我从 posix spec 中找到了这个。我不太擅长英语，所以我不太确定我是否正确理解了它们，但据我所知，它说实现可以生成错误号，每个函数参考页上的错误部分都没有指定。那么为什么 'may fail' 案例在错误部分指定，而它们可以 'may fail' 在任何情况下？
它提供了记录在什么情况下可能使用这些错误代码的机会，并规定了在记录的情况下使用哪些代码。
让我们看看来自同一出版物的 open。
如果“路径名的一个组成部分的长度长于{NAME_MAX}[=35=，它说 open 必须失败并显示 ENAMETOOLONG ]."但是您刚刚收到错误，并且您知道路径名的任何组成部分都不长于 {NAME_MAX}.
好吧，规范还说如果“路径名的长度超过 {PATH_MAX}，或者符号的路径名解析 [=41]，它可能会失败 ENAMETOOLONG =] 产生了一个长度超过 {PATH_MAX}." 的中间结果，这可以帮助您意识到这不是路径问题，而是 symlink 您正在访问。
列出“可能会失败”可以让我们在开始“猜测”之前有更多的事情要检查。
从不同的方向来看我们的示例，我们不希望 POSIX 的一个实现者到 return ENAMETOOLONG 的 symlink 太长, 和另一个实现者 return 一个不同的错误。
记录“可能会失败”的案例可以使实施者始终如一地 returning ENAMETOOLONG 该错误情况。
Then why 'may fail' cases are specified on ERRORS sections when they can 'may fail' on any cases?
因为这些案例
- 指出特定的合理可能的失败情况，
- 指定发生这些情况并导致函数失败时要使用的错误编号，并且
- 为结合特定功能使用特定错误编号建立模型案例（请参阅“实施可能会在描述的情况以外的情况下生成此处列出的错误编号，如果和仅当 所有这些错误条件始终可以与本卷 POSIX.1-2017").
中描述的错误条件相同地处理时
在实践中，“应该失败”和“可能失败”的组合涵盖了观察到的所有失败的绝大多数。允许出现额外错误的函数是实现的安全阀。
The ERRORS section on each reference page specifies which error conditions shall be detected by all implementations ("shall fail") and which may be optionally detected by an implementation ("may fail"). If no error condition is detected, the action requested shall be successful. If an error condition is detected, the action requested may have been partially performed, unless otherwise stated.
Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this volume of POSIX.1-2017. Implementations shall not generate a different error number from one required by this volume of POSIX.1-2017 for an error condition described in this volume of POSIX.1-2017, but may generate additional errors unless explicitly disallowed for a particular function.
我从 posix spec 中找到了这个。我不太擅长英语，所以我不太确定我是否正确理解了它们，但据我所知，它说实现可以生成错误号，每个函数参考页上的错误部分都没有指定。那么为什么 'may fail' 案例在错误部分指定，而它们可以 'may fail' 在任何情况下？
它提供了记录在什么情况下可能使用这些错误代码的机会，并规定了在记录的情况下使用哪些代码。
让我们看看来自同一出版物的 open。
如果“路径名的一个组成部分的长度长于{NAME_MAX}[=35=，它说 open 必须失败并显示 ENAMETOOLONG ]."但是您刚刚收到错误，并且您知道路径名的任何组成部分都不长于 {NAME_MAX}.
好吧，规范还说如果“路径名的长度超过 {PATH_MAX}，或者符号的路径名解析 [=41]，它可能会失败 ENAMETOOLONG =] 产生了一个长度超过 {PATH_MAX}." 的中间结果，这可以帮助您意识到这不是路径问题，而是 symlink 您正在访问。
列出“可能会失败”可以让我们在开始“猜测”之前有更多的事情要检查。
从不同的方向来看我们的示例，我们不希望 POSIX 的一个实现者到 return ENAMETOOLONG 的 symlink 太长, 和另一个实现者 return 一个不同的错误。
记录“可能会失败”的案例可以使实施者始终如一地 returning ENAMETOOLONG 该错误情况。
Then why 'may fail' cases are specified on ERRORS sections when they can 'may fail' on any cases?
因为这些案例
- 指出特定的合理可能的失败情况，
- 指定发生这些情况并导致函数失败时要使用的错误编号，并且
- 为结合特定功能使用特定错误编号建立模型案例（请参阅“实施可能会在描述的情况以外的情况下生成此处列出的错误编号，如果和仅当 所有这些错误条件始终可以与本卷 POSIX.1-2017"). 中描述的错误条件相同地处理时
在实践中，“应该失败”和“可能失败”的组合涵盖了观察到的所有失败的绝大多数。允许出现额外错误的函数是实现的安全阀。