WG15 Defect Report Ref: 14519-10
Topic: Make Section 3.2 optional

This is an approved interpretation of 14519:1994.


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]

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

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.