WG15 Defect Report Ref: 9945-1-06
Topic: order of error numbers

This is an approved interpretation of 9945-1:1990.


Last update: 1997-05-20

                                                                9945-1-90 #6

        Classification: No change required


	Topic:			order of error numbers
	Relevant Sections:	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 

    In 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 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.