Subject: SC22 N2591 - Record of Responses for Defect Reports for 14519 - POSIX Ada Binding

From: "william c. rinehuls" <[email-masked]>
Date: Tue, 7 Oct 1997 17:34:16 -0400 (EDT)

________________ beginning of title page ____________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2591

TITLE:
WG15 Record of Responses for Defect Reports 1 through 10 for: ISO/IEC
14519:1994 - Information technology - Portable Operating System Interface
(POSIX) - POSIX Ada Binding And Letter Ballot

DATE ASSIGNED:
1997-10-07

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Record of Responses for Defect Reports

PROJECT NUMBER:
JTC 1.22.21.04.02

STATUS:
In accordance with SC22 N1236, non-responses to the letter ballot will be
considered as agreement with the proposed record of responses

ACTION IDENTIFIER:
ACT

DUE DATE:
1998-02-09

DISTRIBUTION:
Text

CROSS REFERENCE:
N/A

DISTRIBUTION FORM:
Open

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-9273
email:  [email-masked]

_______________ end of title page; beginning of letter ballot ________
--------------------------------------------------------------------------
Attachment to
JTC 1/SC22 N2591

Circulation Date:  10-24-97

FROM THE MEMBER BODY OF: ____________________________________

On WG15 Proposed Record of Responses for Defect Reports 01 through 10 to:
ISO/IEC 14519:1994 - Information technology - Portable Operating System
Interface (POSIX) - POSIX Ada Binding

This letter ballot is to be returned by each "P" Member Body to the
Secretariat of JTC 1/SC22 by FEBRUARY 9, 1998

-------------------------------------------------------------------------

_____  We agree with the Record of Responses

                   or

_____  We agree with the Record of Responses with the attached comments

                   or

_____  We do not agree with the Record of Responses for the technical
       reasons attached to this ballot

                   or

_____  We abstain from voting.
      
       ("P" MEMBER BODIES HAVE AN OBLIGATION TO VOTE)

*  CHECK WHICHEVER APPLIES.

Name (please print)  _________________________

Signature (if mailed)  _______________________   Date __________
-----------------------------------------------------------------------

_______ end of letter ballot; beginning of document ________________

         WG15 Record of Responses for Defect Reports 101 through 10
                               for
ISO/IEC 14519:1994 - Programming languages - Portable Operating System
                  Interface (POSIX) - POSIX Ada Binding

Below find 9 Records of Response for interpretations/defects as reported
by the U.S. to WG15.  These are numbered with the Standard (IS 14519-1),
followed by a tracking number used in the U.S.

This is proposed to SC22 as a Record of Responses for approval by SC22
for the defects/interpretations indicated in the text.

The specific Defect Reports included are Defect Reports 1, 2, 3, 4, 5, 6,
7, 9 and 10.  A Record of Response was not required for Defect Report 8.

ISO/IEC 14519 Interpretations Log
-----------------------------------------------------------------------
14519-01
     Topic: Missing Parameters from FLUSH_IO Relevant Sections: ISO/IEC
     14519:1994, section 8.2.2.1
14519-02
     Topic: Text on reading from a Pipe Relevant Sections: ISO/IEC
     14519:1994, section 6.1.2,
14519-03
     Topic: Text on writing to pipe Relevant Sections: ISO/IEC
14519:1994,
     section 6.1.2,
14519-04
     Topic: Error checking in Relevant Sections: ISO/IEC 14519:1994:
     section 5.4.1.2,
14519-05
     Topic: Behavior of Read when interrupted by a signal Relevant
     Sections: ISO/IEC 14519:1994: section 6.1.2,
14519-06
     Topic: Can implementation errors raise POSIX_ERROR? Relevant
Sections:
     ISO/IEC 14519:1994: section 2.4.4
14519-07
     Topic: Can IS_A_TERMINAL detect/report errors? Relevant Sections:
     ISO/IEC 14519:1994: section 6.1.4,
14519-09
     Topic: TEXT_IO files should not have EXECUTE Relevant Sections:
     ISO/IEC 14519:1994: section 8.1.1.2
14519-10
     Topic: Make Section 3.2 optional Relevant Sections: ISO/IEC
14519:1994
     3.1, 3.2

------------------------------------------------------------------------
WG15 Defect Report Ref: 14519-01
Topic: Missing Parameters from FLUSH_IO
                                                                14519-92
#1

        Class: Defect situation

The standard omitted some information ( a parameter), and as such
no conformance distinction can be made between alternative
implementations. However, it is recommended that applications avoid use of
this feature; concerns have been raised about this which are being
referred to the sponsor for consideration as a future amendment.

        Topic:                  Missing Parameters from FLUSH_IO
                                generic operations
        Relevant Sections:      ISO/IEC 14519:1994, section 8.2.2.1

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

The FLUSH_IO generic procedure should have a parameter to indicate
exactly which file object should be flushed.  This was the intent of
the operation, as described in the Rationale, and informally during
the development of the standard.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

The standard is currently incorrect, in that the intent was for the
FLUSH_IO operations to have a parameter indicating the specific file
to be flushed.  In the absence of any such parameter, a reasonable
interpretation of the standard as written would be to flush all files
of the appropriate type.  Due to implementation costs, and the
original intent, this interpretation of the standard is not required
of POSIX/Ada implementations.

Until the standard is changed to reflect the original intent,
conforming applications should not use the FLUSH_IO routines.

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

We detected the missing parameters too late in the documentation
process to fix the bug, but the intent was that there would be a
parameter indicating the specific file to be flushed.

An interpretation of FLUSH_IO without any parameters is to flush all
files of the FILE_TYPE used to instantiate the procedure.  However,
this would require substantial changes to current Ada implementations
to maintain the type-specific list of files.  Given this amount of
work, and the original intent, we do not mandate this interpretation
of the standard.  Instead, we strongly suggest that conforming
applications not use this operation until the standard is changed to
reflect the original intent.

Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------

This is planned for the 14519 revision.
________________________________________________________________________

WG15 Defect Report Ref: 14519-02
Topic: Text on reading from a Pipe

-----------------------------------------------------------------------
                                                                14519-92
#2
        Class: Editorial defect
        Topic:                  Text on reading from a Pipe
        Relevant Sections:      ISO/IEC 14519:1994, section 6.1.2,
                                ISO/IEC 9945-1:1990, section 6.4.1.2

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

The text in ISO/IEC 14519 does not fully specify the behavior on
reading from a pipe, as specified by ISO/IEC 9945-1.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

The behavior specified by POSIX.1 for reading from a pipe (POSIX.1
section 6.4.1.2, lines 141-148) also apply to POSIX.5.

In particular, the following text from POSIX.1 applies:

  When attempting to read from an empty pipe (or FIFO):

  (1)  If no process has the pipe open for writing, read() shall return
  zero to indicate end-of-file

  (2)  If some process has the pipe open for writing and O_NONBLOCK is
  set, read() shall return -1 and set errno to [EAGAIN].

  (3)  If some process has the pipe open for writing and O_NONBLOCK is
  clear, read() shall block until some data is written or the pipe is
  closed by all processes that had the pipe open for writing.

The following text indicates the exact semantics of the Ada binding to
the POSIX.1 semantics:

  When attempting to read from an empty pipe (or FIFO):

  (1)  If no process has the pipe open for writing, Read shall raise
  IO_Exceptions.End_Error to indicate end of file.

  (2)  If some process has the pipe open for writing and O_NONBLOCK is
  set, Read shall raise POSIX_Error with the error code
  Interrupted_Operation.

  (3)  If some process has the pipe open for writing and O_NONBLOCK is
  clear, Read shall block until some data is written or the pipe is
  closed by all processes that had the pipe open for writing.

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

The intent for POSIX.5 is to match the POSIX.1 semantics.  The text on
reading from a pipe was omitted from POSIX.5.  As written, POSIX.5
does not contradict this text, and this behavior is generally implied
by other wording in the section, and the general mapping of POSIX.1
semantics in Ada.

Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------
The text will be updated as part of the 14519 revision.
________________________________________________________________________
WG15 Defect Report Ref: 14519-03
Topic: Text on writing to pipe

------------------------------------------------------------------------
                                                                14519-92
#3

        Class: Editorial defect
        Topic:                  Text on writing to pipe
        Relevant Sections:      ISO/IEC 14519:1994, section 6.1.2,
                                ISO/IEC 9945-1:1990, section 6.4.2.2

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

The text in ISO/IEC 14519 does not fully specify the
behavior on writing to a pipe, as specified by ISO/IEC 9945-1.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

The behavior specified by POSIX.1 for reading from a pipe (POSIX.1
section 6.4.2.2, lines 228-253) also apply to POSIX.5.

In particular, the following text from POSIX.1 applies:

  Write requests to a pipe (or FIFO) shall be handled in the same manner
  as write requests to a regular file, with the following exceptions:

  (1)  There is no file offset associated with a pipe, hence each write
  request shall append to the end of the pipe.

  (2)  Write requests of {PIPE_BUF} byte or less shall
  not be interleaved with data from other processes doing writes on the
  same pipe.  Writes of greater than {PIPE_BUF} bytes may have data
  interleaved, on arbitrary boundaries, with writes by other processes,
  whether or not the O_NONBLOCK flag of the file status flags is set.

  (3)  If the O_NONBLOCK flag is clear, a write request may cause the
  process to block, but on normal completion it shall return nbytes.

  (4)  If the O_NONBLOCK flag is set, write() requests shall be handled
  differently, in the following ways:

     (a)  The write() function shall not block the process.

     (b)  A write request for {PIPE_BUF} or fewer bytes shall either:

           [1]  If there is sufficient space available in the pipe,
                transfer all the data and return the number of bytes
                requested.

           [2]  If there is not sufficient space available in the
                pipe, transfer no data and return -1 with errno set to
                [EAGAIN].

     (c)  A write request for more than {PIPE_BUF} bytes shall either:

           [1]  When at least one byte can be written, transfer what
                it can and return the number of bytes written.  When
                all data previously written to the pipe has been read,
                it shall transfer at least {PIPE_BUF} bytes.

           [2]  When no data can be written, transfer no data and
                return -1 with errno set to [EAGAIN].

The following text indicates the exact semantics of the Ada binding to
the POSIX.1 semantics:

  All writes to a pipe shall be appended to the end of the pipe.

  If POSIX_Configurable_File_Limits.Pipe_Length_Is_Limited returns
  True when applied to the file descriptor representing the pipe, then
  the following rules apply, where PIPE_MAX reflects the value returned
  by POSIX_Configurable_File_Limits.Pipe_Length_Limit applied to the
  file descriptor representing the pipe.

     (1)  If Buffer'Length < PIPE_MAX, then the contents of Buffer
          shall not be interleaved with data from other processes doing
          writes on the same pipe.

     (2)  If Buffer'length > PIPE_MAX, the contents of Buffer may be
          interleaved, on arbitrary boundaries, with data written by
          other processes.  This behavior is independent of the
          Non_Blocking option established for the pipe when it is
          created/opened.

     (3)  If the Non_Blocking option is not in effect for the pipe, a
          write request may <or "shall", .1 says "may", but I'm not sure
          I believe this...> cause the process to block.

     (4)  If the Non_Blocking option is in effect for the pipe, and
          Buffer'Length < PIPE_MAX, one of the following shall occur:

           (a)  If there is sufficient space available in the pipe,
                the contents of Buffer shall be written to the pipe.

           (b)  If there is not sufficient space available in the
                pipe, no data shall be transferred, and Write shall
                raise POSIX_Error with the error code
                Interrupted_Operation.

     (5)  If the Non_Blocking option is in effect for the pipe, and
          Buffer'Length > PIPE_MAX, one of the following shall occur:

           (a)  If at least one element can be written, the Write
                operation shall transfer as much of the contents of
                Buffer as can be written.  When all data previously
                written to the pipe has been read, Write shall transfer at
                least PIPE_MAX elements of Buffer before returning.

           (b)  When no data can be written to the pipe, no data shall
                be transferred, and Write shall raise POSIX_Error with 
                the error code Interrupted Operation.

  If POSIX_Configurable_File_Limits.Pipe_Length_Is_Limited returns
  False when applied to the file descriptor representing the pipe, then
  the behavior shall be that specified for Buffer'Length < PIPE_MAX,
  regardless of the actual value of Buffer'Length.

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

The intent for POSIX.5 is to match the POSIX.1 semantics.  The text on
writing to a pipe was omitted from POSIX.5.  As written, POSIX.5
does not contradict this text, and this behavior is generally implied
by other wording in the section, and the general mapping of POSIX.1
semantics in Ada.

Editorial note for future revision of standard (not part of the
interpretation)
-----------------------------------------------------------------------
This will be included in the 14519 revision.
________________________________________________________________________
WG15 Defect Report Ref: 14519-04
Topic: Error checking in

-----------------------------------------------------------------------
                                                                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.
________________________________________________________________________
WG15 Defect Report Ref: 14519-05
Topic: Behavior of Read when interrupted by a signal

-----------------------------------------------------------------------
                                                                14519-92
#5

Class: Ambiguous

The standard is unclear on this issue, and no  conformance distinction
can be made on alternative implementations based on this. It is thus
possible that the standard could be read to conflict with the C language
binding, which was not the intent. This will be referred to the sponsor
for clarifying wording in the next amendment.

        Topic:                  Behavior of Read when interrupted by a
	                        signal
        Relevant Sections:      ISO/IEC 14519:1994:  section 6.1.2,
                                ISO/IEC 9945-1:1990:  section 6.4.1.2

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

What exactly is the behavior of a read operation when interrupted by a
signal?  Is it partial read with a normal return, or is POSIX_ERROR
raised with the error code INTERRUPTED_BY_SIGNAL?

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

POSIX.1, lines 125-128, clarifies the exact behavior of read() in the
face of signals.  EINTR is returned if -NO- data can be read,
otherwise a partial read occurs.

POSIX.5 does not make this distinction clear, but the intent is to
match POSIX.1.  Therefore, POSIX_Error (error code
Interrupted_Operation) shall be raised when the operation is
interrupted by a signal and no data has been transferred.  If some
data has been transferred, and the operation is interrupted by a
signal, then Read shall transfer this data into Buffer and return the
number of elements transferred in the parameter Last.

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

POSIX.5 does not prohibit the behavior specified in POSIX.1, nor does
it make it clear.  This interpretation clarifies the exact behavior of
POSIX.5 to match POSIX.1.

Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------

We will add text to make this distinction clear in the 14519 revision.

________________________________________________________________________
WG15 Defect Report Ref: 14519-06
Topic: Can implementation errors raise POSIX_ERROR
                                                            14519-92
#6

Class: No change
        Topic:                  Can implementation errors raise
                                POSIX_ERROR?
        Relevant Sections:      ISO/IEC 14519:1994:  section 2.4.4

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

The standard is not clear on whether an implementation may raise
POSIX_ERROR for implementation-defined and detected error conditions.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

Implementations may raise POSIX_Error for implementation-defined error
conditions.

Implementations may return implementation-defined values of type
Error_Code.  However, an implementation-defined value must not
conflict with a POSIX-defined value.  The implementation-defined
values of type Error_Code may not defined in package POSIX; they must
be defined in an implementation-specific package.  The function
POSIX.Image on Error_Code should return the constant named defined in
the implementation-defined package.

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

This is the intent, and is the reason why the type Error_Code is
defined to permit implementation extensions, as documented in the
rationale.   For instance, if the implementation wishes to add a new
error condition "Kernel_Is_Trashed", it should define a package akin to
the following:

     with POSIX;
     package Implementation_Errors is

         Kernel_Is_Trashed : constant POSIX.Error_Code
                                            := 42;
           -- value must not conflict with values in package POSIX

     end Implementation_Errors;

The function POSIX.Image (Implementation_Errors.Kernel_Is_Trashed)
should return the string "Kernel_Is_Trashed" (and not
"Implementation_Errors.Kernel_Is_Trashed").

Note that a nice feature of Ada9X will be that the
implementation-defined error codes can be defined in a child package
of package POSIX.  However, this is not supported by Ada83, and this
is an Ada83 binding.
________________________________________________________________________
WG15 Defect Report Ref: 14519-07
Topic: Can IS_A_TERMINAL detect/report errors?

------------------------------------------------------------------------
                                                                14519-92
#7

        Class: Defect situation

The standard requires different behavior to the C language binding
for conforming implementations. This is beingreferred to the sponsor for
clarifying wording in the next amendment
        Topic:                  Can IS_A_TERMINAL detect/report errors?
        Relevant Sections:      ISO/IEC 14519:1994:  section 6.1.4,
                                ISO/IEC 9945-1:1990:  section 4.7.2

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

ISO/IEC 9945-1 does not specify that isatty() can detect or report
any errors.  ISO/IEC 14519 specifies errors that are required to be
detected/reported by IS_A_TERMINAL.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

The standard is currently incorrect, in that it should not require
Is_A_Terminal to detect any errors.  However, Is_A_Terminal is still
required to return True if it can 'prove' that the parameter File is
associated with a terminal.

Conforming applications should not assume that a value of False
returned by Is_A_Terminal indicates that no errors as specified in
POSIX.5 6.1.4 were detected.

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

POSIX.1 clearly does not require error checking, but it strongly
implies that a 'success' value (1) can be trusted.  A failure value
means either that the file descriptor is not a terminal, or that some
other error occurred.  Therefore, conforming POSIX.5 applications can
depend on the value True indicates a terminal device, but cannot apply
any additional meaning to the value False returned by Is_A_Terminal.

Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------
This wording will be corrected in the 14519 revision.
_______________________________________________________________________
WG15 Defect Report Ref: 14519-09
Topic: TEXT_IO files should not have EXECUTE

-----------------------------------------------------------------------
                                                                14519-92
#9

Class: No change
        
        Topic:                  TEXT_IO files should not have EXECUTE
                                rights by default
        Relevant Sections:      ISO/IEC 14519:1994:  section 8.1.1.2

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

The default protection for a file created by TEXT_IO is currently
specified to be READ_WRITE_EXECUTE.  This results in text files that
can be inadvertently executed (as shell scripts), even though that is
not the intent.  The default protection for a file created using
POSIX_IO does not include EXECUTE, so TEXT_IO files should not include
EXECUTE, either.

WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------

The standard is correct as written.  Although the common definition of
text file does not require the file to have Execute permissions, there
is nothing to prevent the user from using Ada's TEXT_IO to write

shellscripts that should be executable.

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

The basic analogy for this is to look at the protections on a file
created by the POSIX.1 creat() operation.  This operation does not
automatically mask out the EXECUTE bits.  Therefore, despite the
appeal of restricting TEXT_IO files to READ and WRITE permissions
only, the standard does 'the right thing'.

Note that the user can prevent EXECUTE privileges via either his
process permission set or via an explicit permission string passed as
part of the TEXT_IO form parameter.

Here is an interesting question for the Ada Rapporteur Group:  Can an
implementation provide something besides the null string "" as the
default for the TEXT_IO Form parameter?
________________________________________________________________________
WG15 Defect Report Ref: 14519-10
Topic: Make Section 3.2 optional

------------------------------------------------------------------------
                                                                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.

____________________ end of SC22 N2591 ____________________________