186 lines
8.2 KiB
Plaintext
186 lines
8.2 KiB
Plaintext
|
|
|||
|
|
| >From uunet!swe.ncsl.nist.gov!cincotta Fri Dec 7 11:23:34 1990
|
|||
|
|
| Received: from SWE.NCSL.NIST.GOV by uunet.UU.NET (5.61/1.14) with SMTP
|
|||
|
|
| id AA03137; Fri, 7 Dec 90 13:13:48 -0500
|
|||
|
|
| Received: by swe.ncsl.nist.gov (4.1/NIST(rbj/dougm))
|
|||
|
|
| id AA04973; Fri, 7 Dec 90 13:15:22 EST
|
|||
|
|
| Date: Fri, 7 Dec 90 13:15:22 EST
|
|||
|
|
| >From: Tony Cincotta <uunet!swe.ncsl.nist.gov!cincotta>
|
|||
|
|
| Organization: National Institute of Standards and Technology (NIST)
|
|||
|
|
| Sub-Organization: National Computer Systems Laboratory
|
|||
|
|
| Message-Id: <9012071815.AA04973@swe.ncsl.nist.gov>
|
|||
|
|
| To: microsoft!markl
|
|||
|
|
| Subject: Your Draft 11.0 Part 2, P1003.3 ballot resolutions
|
|||
|
|
|
|
|||
|
|
|
|
|||
|
|
| Included in this message are the resolutions of Part 2 of your P1003.3
|
|||
|
|
| Ballot of Draft 11.0 (January 24, 1990). Please acknowledge receipt
|
|||
|
|
| of this message.
|
|||
|
|
|
|
|||
|
|
| ALL ballot items marked ACCEPT_WITH_MODS or REJECT will be considered
|
|||
|
|
| as ACCEPTED BY YOU THE BALLOTTER. If you initially objected to an item
|
|||
|
|
| and do not accept the resolution of that item, or have not been given
|
|||
|
|
| enough information on the resolution of the item you may take one of the
|
|||
|
|
| following possible actions:
|
|||
|
|
| 1) REJECT the resolution with no additional comments. We will then
|
|||
|
|
| publish the item as an Unresolved Objection in the next
|
|||
|
|
| recirculation ballot. Please provide the "Identification number"
|
|||
|
|
| of these items.
|
|||
|
|
| 2) Request additional information on the actual changes made to the
|
|||
|
|
| draft.
|
|||
|
|
| 3) REJECT the resolution and provide additional comments for
|
|||
|
|
| consideration. This item will then be discussed by the TR
|
|||
|
|
| committee and if your ballot item is not completely accepted
|
|||
|
|
| by the TR committee, a TR will get in touch with you.
|
|||
|
|
| 4) Wait for the next draft.
|
|||
|
|
|
|
|||
|
|
| Please mail all responses to this message to cincotta@swe.ncsl.nist.gov.
|
|||
|
|
| I will forward the info to the responsible individual. Mail received
|
|||
|
|
| after January 2, 1991 may not be considered for inclusion in the next
|
|||
|
|
| P1003.3.1 recirculation.
|
|||
|
|
|
|
|||
|
|
|
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 Section(s) 3.1.2.2 Page(s) 37 Line(s) 258-262
|
|||
|
|
| Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
|||
|
|
| Identification: 0121 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:ACCEPT_WITH_MODS:
|
|||
|
|
| Prefix assertion 30 with "If the implementation supports a method
|
|||
|
|
| for setting the S_ISUID mode bit:
|
|||
|
|
| Change assertion type to C.
|
|||
|
|
|
|
|||
|
|
| Prefix assertion 31 with "If the implementation supports a method
|
|||
|
|
| for setting the S_ISGID mode bit:
|
|||
|
|
| Change assertion type to C.
|
|||
|
|
|
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 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: 0122 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:DISCUSSION:
|
|||
|
|
| Change to C type assertions with the condition:
|
|||
|
|
|
|
|||
|
|
| "If the implementation provides a mechanism to create a list of
|
|||
|
|
| supplementary Ids for a process"
|
|||
|
|
|
|
|||
|
|
| TR3:
|
|||
|
|
| I see no reason for changing this text.
|
|||
|
|
|
|
|||
|
|
| POSIX.1 defines NGROUPS_MAX as an option. POSIX.1 does not define
|
|||
|
|
| the method of implementing NGROUPS_MAX. Therefore, according to
|
|||
|
|
| our definition for "conditional features" the method of implementing
|
|||
|
|
| NGROUPS_MAX is not a conditional feature.
|
|||
|
|
|
|
|||
|
|
| This is a PCTS installation procedure.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:REJECT:
|
|||
|
|
|
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 Section(s) 4.7.1.2 Page(s) 101 Line(s) 621-624
|
|||
|
|
| Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
|||
|
|
| Identification: 0123 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:DISCUSSION:
|
|||
|
|
| TR1:
|
|||
|
|
| Change to C type assertions with the condition "If the implementation
|
|||
|
|
| provides a method for allocating a controling terminal:"
|
|||
|
|
|
|
|||
|
|
| TR3:
|
|||
|
|
| The process should already have a controlling terminal. The PCTS doesn't
|
|||
|
|
| have to establish a process with a different controlling
|
|||
|
|
| terminal to check these assertions.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:REJECT:
|
|||
|
|
|
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 Section(s) 5.1.2.2 Page(s) 110 Line(s) 104-105
|
|||
|
|
| Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
|||
|
|
| Identification: 0124 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:REJECT:
|
|||
|
|
| It is at least known that a call to opendir() followed by a call
|
|||
|
|
| to readdir() will cause the underlying directory to be read.
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 Section(s) 5.4.1.4 Page(s) 134 Line(s) 765-768
|
|||
|
|
| Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
|||
|
|
| Identification: 0125 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:ACCEPT:
|
|||
|
|
| ------------------------------------------------------------
|
|||
|
|
| Part 2 Section(s) 5.6.1.1 Page(s) 149 Line(s) 1232-1237
|
|||
|
|
| Balloter: Gregory W. Goddard (206) 867-3629 ...!uunet!microsoft!markl
|
|||
|
|
| Identification: 0126 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.
|
|||
|
|
|
|
|||
|
|
| RESOLUTION:REJECT:
|
|||
|
|
| It is inconceivable that a POSIX.a conforming system does not have
|
|||
|
|
| a character special file and a block special file. There is no
|
|||
|
|
| requirement for the PCTS to create these only for the PCTS to
|
|||
|
|
| know the address of them.
|
|||
|
|
|
|