From rinehuls@access.digex.net Tue Oct 7 22:36:05 1997 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA18134 for ; Tue, 7 Oct 1997 22:34:31 +0100 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.8.4/8.8.4) with SMTP id RAA15780 for ; Tue, 7 Oct 1997 17:34:16 -0400 (EDT) Date: Tue, 7 Oct 1997 17:34:16 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2591 - Record of Responses for Defect Reports for 14519 - POSIX Ada Binding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ________________ 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 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 ____________________________