JTC1/SC22
N2591
Date: Tue, 7 Oct 1997 17:34:16 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2591 - Record of Responses for Defect Reports for 14519 - POSIX Ada Binding
________________ 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: rinehuls@access.digex.net
_______________ 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 ____________________________