.
Last update: 1997-05-20
9945-1-90 #6
Classification: No change required
_____________________________________________________________________________
Topic: order of error numbers
Relevant Sections: 2.4, 3.1.2.4
Defect Report:
-----------------------
In 2.4 Error Numbers, page 23, lines 508-510:
"If more than one error occurs in processing a function call,
this part of ISO/IEC 9945 does not define in what order the errors
are detected; therefore any one of the possible errors may be
returned."
In 3.1.2.4 Errors [Execute a file], page 45, lines 178-182 and
page 46, lines 195-196:
"[EACCES] ...
...
[ENOEXEC] The new process image has the appropriate access
permissions, but is not in the proper format."
The definition of the error condition corresponding to [ENOEXEC]
excludes the possibility that it can co-occur with [EACCES].
Nevertheless, it seems to clearly violate the spirit of the
more general requirement, that the order of detection of error
conditions not be specified. Is there a conflict here?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
If an ENOEXEC error can be generated, then the file must have the
correct access permissions, so the EACCES error cannot occur.
If the file does not have the correct access permissions, then
EACCES will occur. There is no conflict.
Rationale for Interpretation:
-----------------------------
The wording in section 2.4 applies only to errors that can
co-occur. The wording in section 3.1.2.4 indeed excludes the
possibility that the [ENOEXEC] and [EACCES] errors can co-occur.
This simply means that the wording in section 2.4 does not apply
to this case. There is no "spirit" of section 2.4 that is
violated here. There are several places in the standard where
one error condition is explicitly worded so that it cannot
co-occur with another error condition. This is often necessary
either to give the caller useful feedback on error conditions or
to prevent violations of access restrictions. The purpose of
the wording in section 2.4 is to avoid implicit and unnecessary
requirements on implementations, and the assumption of such
requirements by application writers. The purpose is not to
prevent the standard from making explicit, useful requirements.
_____________________________________________________________________________