162 lines
6.8 KiB
Plaintext
162 lines
6.8 KiB
Plaintext
IEEE 1003.3 Recirculation Ballot
|
||
|
||
|
||
March 20, 1990
|
||
|
||
|
||
To: Computer Society Secritariat
|
||
iEEE Standards Office
|
||
ATTN: P1003.1a Ballot (Bob Pritchard)
|
||
445 Hoes Lane
|
||
Piscataway, NJ 08855-133
|
||
|
||
|
||
I DO NOT approve as a full use standard 1003.3/D11.
|
||
|
||
|
||
------------------------------------------------------------------------------
|
||
Part I Section(s) 7-8 Page(s) 24-26 Line(s) 447-501
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Test result code of UNRESOLVED is too restrictive. Lines 463-464
|
||
require that UNRESOLVED test result codes shall resolve to one of
|
||
the other test codes before a statement of compliance is made.
|
||
|
||
For a (B) assertion, this means that UNRESOLVED must go to PASS, or
|
||
UNTESTED. Since UNTESTED and UNRESOLVED contridict each other,
|
||
UNRESOLVEs must resolve to PASS. This is not acceptible since a
|
||
test can result in UNRESOLVE because "Setup for the assertion test
|
||
failed".
|
||
|
||
If a PCTS requires target system support facilities to setup for a
|
||
test, and the facilities do not exist, then using the above
|
||
rational, the assertion test can go to UNRESOLVE. In this
|
||
situation, the only way to get a statement of complience is to
|
||
implement system support facilities, retest, and get a PASS. This
|
||
is to restrictive.
|
||
|
||
Required Action:
|
||
Add a test result code of UNTESTABLE with the following definition:
|
||
|
||
UNTESTABLE - An assertion test resulted in an UNRESOLVED test result
|
||
code. After careful examinition, it is discovered that the test
|
||
can not be resolved to PASS because the system being tested
|
||
lacks optional target system support facilities that would
|
||
be required to setup for the assertion test.
|
||
|
||
In the chart on page 26, add the UNTESTABLE test result code to all
|
||
cells.
|
||
|
||
------------------------------------------------------------------------------
|
||
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 3.1.2.2 Page(s) 37 Line(s) 258-262
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertions 30 and 31 are classified incorrectly. Since there is no
|
||
portable way of creating an executable file with either the S_ISUID,
|
||
or S_ISGID mode bits set, defining these as (A) assertions is
|
||
inappropriate.
|
||
|
||
Required Action:
|
||
Change assertions 30 and 31 to (B) or (D) assertions.
|
||
|
||
------------------------------------------------------------------------------
|
||
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 4.2.3.2-4.2.3.4 Page(s) 85-86 Line(s) 214-240
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertions 3, 4, 6 are classified incorrectly. Since there is no
|
||
portable way of modifying a process' list of supplementary group
|
||
ID's, testing the information returned by this call is questionable
|
||
if _SC_NGROUPS_MAX is greater than zero. Since there is no portable
|
||
way to set the number of supplementary group id's in a process,
|
||
verifying that the information returned by getgroups() is correct
|
||
can not be done portably.
|
||
|
||
Required Action:
|
||
Change assertions 3, 4, and 6 to (B) or (D) assertions.
|
||
|
||
------------------------------------------------------------------------------
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 4.7.1.2 Page(s) 101 Line(s) 621-624
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertions 3 and 4 are classified incorrectly. Since there is no
|
||
portable way of establishing the controlling terminal for a process,
|
||
there is no way to verify the correctness of this function.
|
||
|
||
Required Action:
|
||
Change assertions 3 and 4 to (B) or (D) assertions.
|
||
|
||
------------------------------------------------------------------------------
|
||
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 5.1.2.2 Page(s) 110 Line(s) 104-105
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertion 8 is classified incorrectly. Since there is no portable
|
||
way of causing the underlying directory to be read, there is no way
|
||
to test when the st_atime field of the directory should be marked
|
||
for update.
|
||
|
||
Required Action:
|
||
Change assertion 8 (B) or (D) assertions.
|
||
|
||
------------------------------------------------------------------------------
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 5.4.1.4 Page(s) 134 Line(s) 765-768
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertion 14 is based on an incorrect assumption. This assertion is
|
||
based on the assumption that creating a directory causes the link
|
||
count of the parent directory to be incremented. This is not always
|
||
the case, and is certainly not required POSIX.1 functionality. The
|
||
link count bias occurs in UNIX systems due to the ".." entry created
|
||
in the new directory. Implementations that support the ".."
|
||
concept, but that do not actually create an entry for ".." do not
|
||
cause the link count of the parent directory to be incremented. The
|
||
description of readdir() allows for directories that contain no
|
||
entry for "..", and therefore do not cause the link count in the
|
||
parent directory to be incremented.
|
||
|
||
Required Action:
|
||
Change assertion 14 to 14(C) and make it read as follows:
|
||
|
||
If {_POSIX_LINK_MAX} <= {LINK_MAX} <= {PCTS_LINK_MAX} and if
|
||
creating a directory causes the link count of the directory in which
|
||
path1 is to be created to be incremented:
|
||
When {LINK_MAX} links to the directory in which path1 is to be
|
||
created already exist, then a call to mkdir(path1,mode) returns
|
||
a value of ((int)-1), sets errno to [EMLINK], and no directory
|
||
is created.
|
||
|
||
------------------------------------------------------------------------------
|
||
------------------------------------------------------------------------------
|
||
Part II Section(s) 5.6.1.1 Page(s) 149 Line(s) 1232-1237
|
||
Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
||
Identification: XXXX
|
||
Position on Submittal: OBJECTION
|
||
|
||
Assertions 4 and 5 are classified incorrectly. Since there is no
|
||
portable way of creating a character special file or a block special
|
||
file, there is no portable way to test these assertions.
|
||
|
||
Required Action:
|
||
Change assertions 4 and 5 to (B) or (D) assertions.
|
||
|
||
------------------------------------------------------------------------------
|