IEEE Standards Interpretation for IEEE Std 1003.5™-1992 - IEEE Standard for Information Technology--POSIX® Ada Language Interfaces--PART 1: Binding for System Application Program Interface (API)
Copyright © 1995 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.
Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.
IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA
October 25, 1995
Interpretation Request #1
Topic: Error checking in POSIX_Configurable_File_Limits Relevant Clauses: 1003.5-1992: 22.214.171.124, 1003.1-1990: 5.7.1 Classification: Defect
IEEE Std 1003.1-1990 does not require that pathconf() check and report errors. This appears to be a requirement in IEEE Std 1003.5-1992.
IEEE Std 1003.5-1992 and IEEE Std 1003.1-1990 require different behavior for conforming implementations in this case. This situation is being referred to the sponsor.
The requirement in IEEE Std 1003.5-1992 is incorrect. The intent was that error checking should only apply when the parameters are used to determine the answer. The specific wording in IEEE Std 1003.1-1990 applies when the pathconf() fildes or fpathconf() path parameter is used to determine the value, or when a specific pathname variable name is associated with a specific file.
If the value can be determined without reference to the File or Pathname parameters, then this text basically states that the implementation is not required to check the File 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 for detecting errors. In particular, when a limit operation does not return an exception (instead returning 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 IEEE Std 1003.1-1990 appears in lines 996-1003. This text establishes 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.