Source code of Windows XP (NT5)
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.
 
 
 
 
 
 

185 lines
8.2 KiB

| >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 [email protected].
| 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.
|