Copyright © 1995 by the Institute of Electrical and Electronics
Engineers, Inc.
345 East 47th Street
New York, New York 10017 USA
All Rights Reserved.
This is an interpretation of IEEE Std 1003.5-1992. Interpretations are issued to explain and clarify the intent of a standard and are not intended to constitute an alteration to the original standard or 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 Standard 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, P. O. Box 1331
Piscataway, New Jersey 08855-1331, USA
October 25, 1995
SH94341
Interpretation Number: 4
Topic: Error
checking in POSIX_Configurable_File_Limits
Relevant Clauses: IEEE Std 1003.5-1992: 5.4.1.2,
IEEE Std 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.
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.
Copyright © 1995 IEEE. All rights reserved.
Interpretation Number: 10
Topic: Make
subclause 3.2 optional
Relevant Clauses: 3.1, 3.2
There is a question about the inclusion of POSIX_Unsafe_Process_Primitives
as a required part of the standard. There is no way these can be
guaranteed to be portable, and the standard basically acknowledges this fact on
page 58 and in the rationale of B.2.3.6. IEEE Std 1003.5-1992 also
provides alternatives to Fork and Exec in 3.1
that allow equivalent functionality in the vast majority of usage.
The claim is in two parts:
The concern is that an implementation that did not implement Fork
and Exec (but that was portable) could not be compliant with the
current standard, while an implementation that did implement them (but that was
not portable) could be.
Therefore, all of 3.2 should be optional, and this option should be
specified as such in the next revision of the standard. This option should
also be named the ADA_UNSAFE_PRIMITIVE option, in accordance with
the PASC Sponsor Executive Committee (SEC) resolution that requires that all
options be labeled with a unique ID.
Circumstances exist where the facilities in 3.1 of IEEE Std 1003.5-1992 [Start_Process]
are insufficient to achieve the underlying POSIX semantics defined in ISO/IEC
9945-1:1990/IEEE Std 1003.1-1990 for fork() and exec(). The Ada
standard clearly specifies conditions under which a Strictly Conforming
Application may use the Fork and Exec family of
operations. Under other circumstances, the behavior of the Fork
and Exec family of operations is specified to be implementation
defined (thereby requiring documentation by the implementor). The requested
interpretation would require a change to the current standard, and this would be
out of scope for an interpretation. No conflict with the semantics of ISO/IEC
9945-1:1990/IEEE Std 1003.1-1990 has been identified.
The Fork and Exec family of operations are
needed to obtain POSIX functionality not provided by Start_Process
operations. Therefore, they are clearly part of the underlying POSIX system
semantics.
The Ada semantics provide some potential implementation pitfalls for
implementors of IEEE Std 1003.5-1992, particularly with respect to the
interaction between Ada tasks and POSIX system calls. Thus, the rule for the "safe"
use of the Fork and Exec family of operations
specifies conditions that can be established by the application programmer.
When these conditions are met, IEEE Std 1003.5-1992 clearly establishes the
semantics, and implementations have to conform under these circumstances. The
minimum set of conditions for the Fork and Exec
family of operations to work was added to the standard during balloting.
Balloters specifically requested that these be added. Thus, it is fair to
assert that making the Fork and Exec family of
operations optional during the original ballot of IEEE Std 1003.5-1992 would
have reduced consensus.
There are two specific claims made in the interpretation request, and neither is valid:
IEEE Std 1003.5-1992 would be incomplete if it did not provide access to
underlying POSIX services. In particular, an application design that plans to
use Fork to create multiple instances of the same program would be
unable to be implemented using IEEE Std 1003.5-1992 without Fork
as defined in 3.2.
The facilities provided in 3.1, for instance, are defined in terms of their underlying POSIX semantics. There is no requirement that a language binding provide one-to-one analogs to services. Rather, the binding should provide access to all services. Thus, the addition of alternate means to access the specific service does not give justification for removing basic functionality.
Finally, given differences between C and Ada naming, the PASC SEC requirement that all options be given unique names need well not apply to Ada, due to the existing facilities in Ada for namespace management. The term "unique" can only be understood within the naming domain of a given language.
Copyright © 1995 IEEE. All rights reserved.
Back to Available IEEE Standards Interpretations Online