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.
I found this from posix spec. I'm not really good at English, so I'm not really sure that I understood them correctly, but as far as I understood, it says that implementations can generate error numbers which is not specified on ERRORS sections on each function reference pages. Then why 'may fail' cases are specified on ERRORS sections when they can 'may fail' on any cases?
CodePudding user response：
Then why 'may fail' cases are specified on ERRORS sections when they can 'may fail' on any cases?
Because these cases
- call out particular reasonably likely circumstances for failure,
- specify the error number to be used if those circumstances occur and cause the function to fail, and
- establish model cases for the usage of particular error numbers in conjunction with particular functions (refer to "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").
In practice, the combination of "shall fail" and "may fail" cases cover the vast majority of all failures observed. The allowance for functions exhibiting additional errors is a safety valve for implementations.
CodePudding user response：
It gives a chance to document under what circumstances those error codes are likely to be used, and it mandates which codes to use in the documented circumstances.
Let's look at open from the same publication.
It say it open must fail with ENAMETOOLONG if "The length of a component of a pathname is longer than {NAME_MAX}." But you just got the error, and you know no component of pathname is longer than {NAME_MAX}.
Well, the spec also says it may fail with ENAMETOOLONG if "The length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}." And this helps you to realize that it wasn't a problem with your path, but a problem with the symlink you were accessing.
Having the "may fails" listed gives us more things to check before we have to start "guessing".
Looking at our example from a different direction, we wouldn't want one implementor of POSIX to return ENAMETOOLONG for symlinks that are too long, and another implementator return a different error.
Having the "may fail" cases documented locks the implementors into consistently returning ENAMETOOLONG for that error condition.