.
Last update: 1997-05-20
14519-92 #10
_____________________________________________________________________________
Topic: Make Section 3.2 optional
Relevant Sections: ISO/IEC 14519:1994 3.1, 3.2
Defect Report:
-----------------------
[The requestor] questions the inclusion of the "POSIX Unsafe
Process Primitives" as a required part of the standard.
There is no way these can be guaranteed portable, and the
standard basically acknowledges this fact on page 58 and in
the rationale of B.2.3.6. This standard also provides
alternatives to fork and exec in the POSIX Process
Primitives (clause 3.1) that allow equivalent functionality
in the vast majority of usage.
[The requestor`s] claim is two part:
1) That compatibility with 9945-1:1990 is not as important
as the portability considerations of [the 14519:1994]
standard.
2) That [14519:1994 is] not compatible with 9945-1:1990 anyway,
since [it has] added additional primitives, and the
additional concept of "packages" of primitives (clauses
3.1, 3.2, and 3.3).
[The requestor`s] concern is that an implementation that did not
implement fork and exec, but was portable, could not be compliant with
the current standard, while an implementation that did implement them,
but was not portable, could be.
[The requestor] therefore requests that an official interpretation be
given that all of clause 3.2 is optional and that this option be
specified as such in the next revision of the standard. [He] also
suggests that this option be named the ADA_UNSAFE_PRIMITIVE option, in
accordance with the SEC resolution which requires that all options be
named with a unique ID.
WG15 response for 14519:1994
--------------------------------------------------
Circumstances exist where the facilities in ISO/IEC 14519:1994 3.1
(START_PROCESS()) are insufficient to achieve the underlying POSIX
semantics defined in ISO 9945-1:1989/ISO/IEC 9945-1:1990 for FORK()
and EXEC(). The standard clearly specifies conditions under which a
Strictly Conforming Application may use FORK() and EXEC(). Under
other circumstances, the behavior of FORK() and EXEC() is specified to
be implementation-defined (thereby requiring documentation by the
implementator.) The requested interpretation would require a change
to the current standard, and would be out of scope for an
interpretation. No conflict with the semantics of ISO
9945-1:1989/ISO/IEC 9945-1:1990 has been identified.
Rationale for Interpretation:
-----------------------------
Fork() and exec() are needed to obtain POSIX functionality not
provided by POSIX.5 3.1 START_PROCESS() operations. Therefore, they
are clearly part of the underlying POSIX system semantics.
The Ada semantics provide some potential implementation pitfalls for
the implementors of the Ada binding, particularly with respect to the
interaction between Ada tasks and POSIX system calls. Thus the rule
for "safe" use of FORK() and EXEC() specifies conditions which can be
established by the application programmer. When these conditions are
met, ISO/IEC 14519:1994 clearly establishes the semantics, and
implementations must conform under these circumstances. The minimum
set of conditions for FORK()/EXEC() to work was added to the standard
during balloting. Balloters specifically requested that these be
added. Thus, it is fair to assert that making FORK()/EXEC() optional
during the orignal 14519 ballot would have reduced consensus.
There are two specific claims made in the interpretation request, and
neither is valid:
1) That compatibility with 9945-1:1990 is not as important
as the portability considerations of their own
standard.
The Ada Binding 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 POSIX.5, without FORK() as
defined in 3.2.
2) That they are not compatible with 9945-1:1990 anyway,
since they have added additional primitives, and the
additional concept of "packages" of primitives (clauses
3.1, 3.2, and 3.3).
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 1-1 analogs to services, but rather that the
binding provide access to all services. Thus the addition of
alternate means to access the specific service is not justification
for removing basic functionality.
Finally, given differences between C and Ada naming, the
requirement that all options be given unique names need well not apply
to Ada, due to Ada's existing facilities for namespace management.
The term "unique" can only be understood within the naming domain of a
given language.
_____________________________________________________________________________