WG15 Defect Report Ref: 14519-04
Topic: Error checking in


This is an approved interpretation of 14519:1994.

.

Last update: 1997-05-20


                                                                14519-92 #4

 _____________________________________________________________________________


	Topic:			Error checking in 
				POSIX_Configurable_File_Limits
	Relevant Sections:	ISO/IEC 14519:1994:  section 5.4.1.2,
			     	ISO/IEC 9945-1:1990:  section 5.7.1
	Classification:		Defect


Defect Report:
-----------------------

ISO/IEC 9945-1 does not require that pathconf() check and report
errors.  This appears to be a requirement in ISO/IEC 14519.

WG15 response for 14519:1994 
-----------------------------------

The Ada language binding (ISO/IEC 14519:1994) and the C language binding 
(ISO/IEC 9945-1:1990) require different
behavior of conforming implementations in this case. This situation is
being referred to the sponsors.

This requirement in ISO/IEC 14519 is incorrect, in that the intent was 
that the error checking only applies when the parameters are used to determine
the answer.  The specific wording in POSIX.1 applies when the
pathconf() fildes or fpathconf() path parameter are used to determine
the value, or with the association of a specific pathname variable
name with a specific file.

If the value can be determined without reference to the fildes or path
parameters, then this text POSIX.1 basically states that the
implementation is not required to check the filedes parameter for
validity, if it is not used.

The other condition applies when the implementation can determine that
the named limit does not apply to the given file.  In this case, the
implementation is required to detect the error as stated.  This case
only applies when the implementation has this restriction in the first
place.  (In other words, if the implementation places this
restriction, it is required to report it.  If it does not have this
restriction, there is no cause for error checking.)

Conforming applications should not depend on the limits operations
detecting errors.  In particular, when a limit operation does not
return an exception (instead it returns a limit value or boolean
indication), an application should not assume that the parameter to
the limit function is valid.

Rationale for Interpretation:
-----------------------------

The specific text in POSIX.1 that applies is lines 996-1003.  This
text establish that this error checking only applies when the parameters
are used to determine the value to be returned.  If the parameters are
not used, then there is no requirement to check the validity of the
parameters.  

 _____________________________________________________________________________