|
|
OBJECTION Part I, Section 4.0, Page 13, Lines 84-86
The definition of PCTS shall be a conforming application is too vauge.
REQUIRED ACTION: Add the following to this paragraph: The PCTS shall be a "Strictly Conforming POSIX Application".
If the PCTS requires a certain environment available on the target system, it shall be possible to create that environment using a Strictly Conforming POSIX.1 Application. If such an application is required, then the PCTS shall include such an application.
Environment includes the presence of a named file protected in a certain way, the presence and contents of any directory or file hierarchy...
--- NEW PAGE ---
OBJECTION Part I, Section 5.0, Page 14, Line 107
Specification of software requirements is too vauge.
REQUIRED ACTION: Add the following to this line: The specification of software requirements necessary to execute the PCTS shall be confined to an environment that may be created using a PCTS supplied Strictly Conforming POSIX.1 Application.
------------------------------------------------------------------------------
OBJECTION Part I, Section 5.0, Page 14, Lines 109-110
Description of procedure to transfer PCTS to target system is too open ended.
REQUIRED ACTION: Add the following to this line: If the PCTS requires a transfer to the target system. The procedure used to transfer the PCTS shall be a Strictly Conforming POSIX.1 Application supplied with the PCTS. All PCTS's shall be transferable from the development system to the target system. All PCTS's must contain this documentation and the corresponding Strictly Conforming POSIX.1 Application necessary to transfer the PCTS.
--- NEW PAGE ---
------------------------------------------------------------------------------
OBJECTION Part I, Section 10.0, Page 22, Lines 301-303
A result code of FAIL should not be possible for an extended assertion.
REQUIRED ACTION: Change the table as follows: For required feature extended assertions, permissable result codes shall be limited to PASS or UNTESTED.
For optional feature extended assertions, permissable result codes shall be limited to PASS, UNSUPPORTED, or UNTESTED.
It shall not be possible to FAIL an extended assertion. The POSIX.3 Draft has made a very clear distinction between base assertions, and extended assertions. Base assertions shall be tested and are infact testable. Extended assertions which do not require a test should not effect an implementations ability to acheive complience.
Since assertions are classified as extended assertions when the assertion is not testable, failing such a test should not be possible and should not effect an implementations ability to acheive compliance.
--- NEW PAGE ---
------------------------------------------------------------------------------
OBJECTION Part I, Section 13.0, Page 26, Lines 365-367
The result code of an extended assertion should have no bearing on an implementations designation as compliant.
REQUIRED ACTION: Remove lines 365-368 from this document. The POSIX.3 Draft has made a very clear distinction between base assertions, and extended assertions. Base assertions shall be tested and are infact testable. Extended assertions which do not require a test should not effect an implementations ability to acheive complience.
Since assertions are classified as extended assertions when the assertion is not testable, failing such a test should not be possible and should not effect an implementations ability to acheive compliance.
--- NEW PAGE ---
OBJECTION Part I, Section 8.0, Page 19, Line 215
Specification of setup procedures and effort is too vauge.
REQUIRED ACTION: Add the following to this line: If testing of the assertion requires setup procedures or effort on the part of the testor that is not possible to acheive using a Strictly Conforming POSIX.1 Application, then the assertion shall not be considered an assertion, base assertion, or an extended assertion. If a PCTS attempts to test such an assertion, the results of the test shall not affect the implementations conformance/compliance and no record of the test shall appear in any PCTS output.
--- NEW SECTION ---
OBJECTION Part II, Section 1.2.1, Page 2,3, Lines 27-47
This section places an unacceptable burden on an implementation.
REQUIRED ACTION: Add the following to this section: If testing an assertion requires that an operational environment be created which requires the target system to provide functionality which is beyond the scope of POSIX.1, that assertion shall be declared a "non-assertion" which by definition is UNTESTABLE and can not be used to determine an implementations compliance.
Under no circumstances should it be permissible to require a target system which is claiming POSIX.1 complience to provide additional features outside the scope of POSIX.1. To do this would place an unacceptable burden on those implementations that are hosted, or are designed in clean room conditions in accordance with the documented POSIX.1 standard.
It shall be possible to fully test an implementation that only provides those features described in POSIX.1. Such a system shall be a compliant system.
If an implementation choses to support additional features which are outside the scope of POSIX.1, but if implemented would allow the testing of a previously UNTESTABLE assertion, then the assertion may be tested as an extended assertion. The results of any such assertion test shall have no impact on an implementations ability to acheive compliance.
If testing of the assertion requires setup procedures or effort on the part of the testor that is not possible to acheive using a Strictly Conforming POSIX.1 Application, then the assertion shall not be considered an assertion, base assertion, or an extended assertion. If a PCTS attempts to test such an assertion, the results of the test shall not affect the implementations conformance/compliance and no record of the test shall appear in any PCTS output.
The rationale used to arrive at the current draft of this section is flawed. It does not consider hosted implementations or implementations developed under clean room conditions. The rationale assumes that PCTS's will be targeted at a limited set of implementations where the required facilities could be provided in a standard way. This assumes that all POSIX.1 implementations are acheived by having a vendor modify its current UNIX product such that it supports the required POSIX.1 facilities. The target system support facility would be provided by the underlying AT&T derived UNIX system. Not all implementations of POSIX.1 are derived from AT&T source code, or are acheived my modifying an existing UNIX system. Clean room implementations of POSIX where the only documentation is the POSIX.1 standard must be addressed. The only way to adequetly address these systems is to allow an implementation that only implements those facilities documented in POSIX.1 to be considered as a POSIX.1 compliant system. It would be improper for this document to demand that UNIX like support facilities are needed in order to implement POSIX.1.
-------------------------------------------------------------------------------
OBJECTION Part II, Section 1.2.1.2, Page 3, Lines 45-47
Providing a "target system support facility" should not be a requirement of a POSIX.1 implementation.
REQUIRED ACTION: Revise this section. Any assertion that requires an implementation to provide a "target system support facility" that is beyond the scope of POSIX.1 shall be classified as an untestable assertion. The outcome of a test on such an assertion shall have no bearing on an implementations ability to acheive compliance, and shall not appear in any output from a PCTS.
It shall be possible to fully test an implementation that only provides those features described in POSIX.1. Such a system shall be a compliant system.
Failure allow a system which provides only those facilities described in POSIX.1 to be classified as a compliant system is unacceptable. If additional facilities are required, then the time should be taken to extend POSIX.1 to incorporate such facilities.
There are many situations in hosted implementations, or in implementations developed under "clean room" conditions where the POSIX.1 documentation is the only documentation used to design an implementation.
Approval of this section and section 1.9 would force many of these implementations to choose a PCTS based on its test coverage, and the demands that it placed on the target support facility.
This document must allow for a PCTS that requires only those facilities provided by POSIX.1.
-------------------------------------------------------------------------------
OBJECTION Part II, Section 1.9, Page 7,8, Lines 208-228
This section places an unacceptable burden on the target hardware.
REQUIRED ACTION: remove the closed-loop requirement. It is unacceptable to require that a target system support multiple terminal ports. It shall be possible to build a POSIX.1 compliant system that has no asynchronous communication ports. It shall be acceptable to implement a POSIX.1 compliant system whose only "terminal like" input output capabilities are implemented as a layer ontop of the keyboard/display hardware commonly found on Workstations and PC's.
--- NEW PAGE ---
-------------------------------------------------------------------------------
OBJECTION Part II, Section 7, Page 158-184, Lines 2-709
Terminals, and are not well defined.
REQUIRED ACTION: Make all assertions in this section optional, or extended assertions.
The note on line 6 of this section sums up the problems with the section. Major portions of this section are only valid when a terminal is an "asynchronous serial terminal".
There are systems that whose I/O system consists of a disk, video controller, and keyboard input. It shall be possible to to classify such a system as POSIX.1 compliant.
An implementation for such a target system would have to fail all calls to isatty() since its I/O system is not capable of supporting all assertions specified in this section.
|
