Use of the information contained in this unapproved document is at your own risk.

Last update: 10 April,2001

                                                                1003.1-90 #6

        Classification: No change required


This response will be incorporated in an IEEE interpretations
publication, and will be also made available on-line on the IEEE 
SPAsystem.

 _____________________________________________________________________________


	Interpretation Number:	XXXX
	Topic:			order of error numbers
	Relevant Sections:	2.4, 3.1.2.4


Interpretation Request: (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?

IEEE Interpretation for 1003.1-1990 (9945-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.


 _____________________________________________________________________________