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.