mirror of https://github.com/tongzx/nt5src
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
276 lines
11 KiB
276 lines
11 KiB
|
|
|
|
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.
|