Document Number: AUSTIN/60r2 Title: XBDd4 Aardvark Change Request Report (FINAL) Revision Date: 2000-12-14 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XBD Draft 4. Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Reject ERN 3 Accept ERN 4 Accept ERN 5 Accept ERN 6 Accept ERN 7 Accept ERN 8 Accept ERN 9 Accept ERN 10 Accept ERN 11 Accept ERN 12 Accept ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Reject ERN 17 Duplicate of indiv ballot comments ERN 18 Accept ERN 19 Reject ERN 20 Accept ERN 21 Accept ERN 22 Accept ERN 23 Accept as marked ERN 24 Accept as marked ERN 25 Accept as marked ERN 26 Accept ERN 27 Accept as marked ERN 28 Accept as marked ERN 29 Accept as marked ERN 30 Accept as marked ERN 31 Accept as marked ERN 32 Accept as marked ERN 33 Accept as marked ERN 34 Accept ERN 35 Accept ERN 36 Accept as marked ERN 37 Accept as marked ERN 38 Accept ERN 39 Accept ERN 40 Accept ERN 41 Accept as marked ERN 42 Duplicate of 43 ERN 43 Accept as marked ERN 44 Accept ERN 45 Accept as marked ERN 46 Accept as marked ERN 47 Accept as marked ERN 48 Accept as marked ERN 49 Accept ERN 50 Accept as marked ERN 51 Accept as marked ERN 52 Duplicate of 46 ERN 53 Accept as marked ERN 54 Accept as marked ERN 55 Accept as marked ERN 56 Accept ERN 57 Accept as marked ERN 58 Accept as marked ERN 59 Accept ERN 60 Accept as marked ERN 61 Accept ERN 62 Accept as marked ERN 63 Accept ERN 64 Accept ERN 65 Accept ERN 66 Accept ERN 67 Accept as marked ERN 68 Accept ERN 69 Accept ERN 70 Reject ERN 71 Accept ERN 72 Accept ERN 73 Accept ERN 74 Accept ERN 75 Accept ERN 76 Accept ERN 77 Accept ERN 78 Accept ERN 79 Reject ERN 80 Accept ERN 81 Accept as marked ERN 82 Accept ERN 83 Reject ERN 84 Accept ERN 85 Accept ERN 86 Accept as marked ERN 87 Accept ERN 88 Accept ERN 89 Accept ERN 90 Accept ERN 91 Accept ERN 92 Accept ERN 93 Accept as marked ERN 94 Accept as marked ERN 95 Accept as marked ERN 96 Accept ERN 97 Accept ERN 98 Accept ERN 99 Accept as marked ERN 100 Accept ERN 101 Accept ERN 102 Accept ERN 103 Accept ERN 104 Accept ERN 105 Accept ERN 106 Accept ERN 107 Accept ERN 108 Accept ERN 109 Accept ERN 110 Accept as marked ERN 111 Accept ERN 112 Accept as marked ERN 113 Accept as marked ERN 114 Accept ERN 115 Accept ERN 116 Reject ERN 117 Reject ERN 118 Accept ERN 119 Accept ERN 120 Accept ERN 121 Accept ERN 122 Accept ERN 123 Accept ERN 124 Accept as marked ERN 125 Accept ERN 126 Duplicate of 127 ERN 127 Reject ERN 128 Reject ERN 129 Accept ERN 130 Accept as marked ERN 131 Accept ERN 132 Accept as marked ERN 133 Accept as marked ERN 134 Reject ERN 135 Reject ERN 136 Accept ERN 137 Accept ERN 138 Accept ERN 139 Accept ERN 140 Accept ERN 141 Accept ERN 142 Accept ERN 143 Accept as marked ERN 144 Accept ERN 145 Accept ERN 146 Accept ERN 147 Reject ERN 148 Accept ERN 149 Accept ERN 150 Accept ERN 151 Reject ERN 152 Accept ERN 153 Accept ERN 154 Duplicate of 83 ERN 155 Accept as marked ERN 156 Accept as marked ERN 157 Accept as marked ERN 158 Reject ERN 159 Accept ERN 160 Accept ERN 161 Accept ERN 162 Accept ERN 163 Accept ERN 164 Accept ERN 165 Accept as marked ERN 166 Accept ERN 167 Accept ERN 168 Accept ERN 169 Accept ERN 170 Reject ERN 171 Accept ERN 172 Accept ERN 173 Accept ERN 174 Accept ERN 175 Accept ERN 176 Accept ERN 177 Accept as marked ERN 178 Accept ERN 179 Accept ERN 180 Accept ERN 181 Accept ERN 182 Accept as marked ERN 183 Duplicate of 182 ERN 184 Accept ERN 185 Accept ERN 186 Accept ERN 187 Accept ERN 188 Accept ERN 189 Accept ERN 190 Accept ERN 191 Accept as marked ERN 192 Accept ERN 193 Accept as marked ERN 194 Accept ERN 195 Accept ERN 196 Accept as marked ERN 197 Accept ERN 198 Accept ERN 199 Reject ERN 200 Accept ERN 201 Accept ERN 202 Accept as marked ERN 203 Accept as marked ERN 204 Accept ERN 205 Accept ERN 206 Accept as marked ERN 207 Accept as marked ERN 208 Accept ERN 209 Duplicate of 208 ERN 210 Accept ERN 211 Duplicate of 212 ERN 212 Accept as marked ERN 213 Accept ERN 214 Accept ERN 215 Accept ERN 216 Accept ERN 217 Accept ERN 218 Accept as marked ERN 219 Accept ERN 220 Accept as marked ERN 221 Accept ERN 222 Accept ERN 223 Duplicate of 224 ERN 224 Duplicate of 222 ERN 225 Accept ERN 226 Accept as marked ERN 227 Accept ERN 228 Accept ERN 229 Accept ERN 230 Accept ERN 231 Accept ERN 232 Accept as marked ERN 233 Accept ERN 234 Accept as marked ERN 235 Accept ERN 236 Accept ERN 237 Reject ERN 238 Accept as marked ERN 239 Accept ERN 240 Accept as marked ERN 241 Accept ERN 242 Accept ERN 243 Accept as marked ERN 244 Accept as marked ERN 245 Duplicate of 244 ERN 246 Accept as marked ERN 247 Accept as marked ERN 248 Accept as marked ERN 249 Accept ERN 250 Accept as marked ERN 251 Accept as marked ERN 252 Accept as marked ERN 253 Accept ERN 254 Reject ERN 255 Accept as marked ERN 256 Reject ERN 257 Accept ERN 258 Accept ERN 259 Accept as marked ERN 260 Accept as marked ERN 261 Duplicate of 262 ERN 262 Accept as marked ERN 263 Accept ERN 264 Reject ERN 265 Reject ERN 266 Accept ERN 267 Accept ERN 268 Reject ERN 269 Accept as marked ERN 270 Accept as marked ERN 271 Accept as marked ERN 272 Accept as marked _____________________________________________________________________________ Comment Enhancement Request Number 1 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 188) [DWC-780] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: (C99 headers) Earlier objections in my ballot have noted that the introductory paragraph in the DESCRIPTION section of the Standard C headers (the one stating how the requirements in this revision relate to the C99 requirements for those headers) is consistently wrong. See my objections on , [DWC-761]; , [DWC-762]; , [DWC-764]; , [DWC-766]; , [DWC-767]; , [DWC-771]; , [DWC-774]; , [DWC-775]; , [DWC-777]; , [DWC-778]; and , [DWC-779]. Action: Check the rest of the Standard C header descriptions (, , , , , , , , , , , , and ) for similar problems. [Ed recommendation: Accept as marked. This is a standard header block that we use, that is here to alert the user that this standard is an extended profile of ISO C, and that the features, functions etc are activated under the appropriate namespace. We had a different mark for headers as we did not intend adding CX markings. We'll need to review this change in the light of what we decide elsewhere, and believe we should make the change globally to to all ISO C header pages irrelevant of the level of extension] ------------------------------------------------------------------------------ _______________________________________________________________________________ objection Enhancement Request Number 2 roysterc@ncr.disa.mil Bug in XBDd4 entire Document (rdvk# 192) {App usage section(s)/entire document} Wed, 27 Sep 2000 03:30:31 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: If we make this change we'd need to update this standard each time a new profile is written. It is also not appropriate to put normative text in informative frontmatter. The Option groups are already described in one location in conformance definitions. It is also inappropriate to refer to a standard which is a profile of an earlier version of this standard. Additional option groups have been added to support profiling, details of that profiling should be external to this document. _______________________________________________________________________________ Page: 0 Line: 0 Section: entire Problem: Need to identify all of the different types of Feature Groups b4 approving this draft. Also, each API/Function should be labeled to indicated if it is part of an existing POSIX profile like 1003.13:1998. This will inform the implementor to maybe use this API by profile name (1003.13:1998 PSE54 instead of standard reference number e.g., 1003.1:xxxx. Action: In the Front section of the document. List all the types of feature groups with their meanings. Also, list if a particular API/function is part of an existing profile like 1003.13:1998 etc. The application usage section should indicate if a function/API is listed in 1003.13:1998. If an API is not noted, this would be helpful to the implementor/user of the spec. _____________________________________________________________________________ comment Enhancement Request Number 3 ieee.balloter BUG in P1003.1/D4 (rdvk# 213) [baker@cs.fsu.edu_969225910.19011_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have been monitoring the Austin Group "aardvark" list and am satisfied that if the issues raised there are corrected the document will be satisfactory as an IEEE standard. Action: See problem. _____________________________________________________________________________ objection Enhancement Request Number 4 ieee.balloter BUG in P1003.1/D4 (rdvk# 204) [keld@rap.dk_969961447.3049_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I refer to our comments to the Austin group. Action: If these are resolved satisfactorily, the vote will be changed to "yes _____________________________________________________________________________ editorial Enhancement Request Number 5 ieee.balloter BUG in P1003.1/D4 (rdvk# 203) [chammons@mindspring.com_969886491.24250_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have been balloting for some time and this is the first email based exercise. I have enjoyed being in the middle of all the comments and discussions. In spite of the volume of email, I believe it to be most benificial and time saving. All issues I have looked at have been discovered by other members and have been fully discussed. Thank you. Action: See problem. _____________________________________________________________________________ objection Enhancement Request Number 6 ieee.balloter BUG in P1003.1/D4 (rdvk# 212) [gwinn@res.ray.com_970005254.10578_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have been been both monitoring the Austin Group "aardvark" list and submitting comments and will be satisfied when my specific comments (and objections) are resolved, those of {Mike Gonzales, Karen Gordon, Jim Oblinger, Frank Prindle, Pierre-Jean Arcos, Francois Riche} are resolved, as well as the rest of the issues raised in the Austin Group list. Action: See Comment field. _____________________________________________________________________________ objection Enhancement Request Number 7 ieee.balloter BUG in P1003.1/D4 (rdvk# 211) [mgh@unican.es_969950064.1808_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I fully support the objections that Frank Prindle has submitted to The Open Group in aardvark format. My IEEE ballot objections can be resolved by fully resolving those objections. Action: For each objection submitted by Frank Prindle to the Open Group in aardvark format, perform the action designated in the "Action:" aardvark field. _____________________________________________________________________________ objection Enhancement Request Number 8 ieee.balloter BUG in P1003.1/D4 (rdvk# 210) [fpm@hotmail.com_969990929.7634_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections submitted to the Austin Group in aardvark format against this document and fully support the majority of those objections. Action: My IEEE ballot objection can be resolved by resolving each and every objection submitted to the Austin Group. [Ed recommendation: Accept] _______________________________________________________________________________ objection Enhancement Request Number 9 ieee.balloter BUG in P1003.1/D4 (rdvk# 209) [kgordon@vuse.vanderbilt.edu_969997088.8787_ieee] Wed Sep 27 16:11:28 BST 2000 _______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _______________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I fully support the objections which Frank Prindle has submitted to Open Group in aardvark format. Action: As far as my IEEE ballot is concerned, these objections can be resolved by fully resolving Frank's objections. _____________________________________________________________________________ objection Enhancement Request Number 10 ieee.balloter BUG in P1003.1/D4 (rdvk# 208) [roger.martin@sun.com_969986992.6874_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections which Don Cragun has submitted to the Austin Group in aardvark format and fully support those objections. My IEEE ballot objections can be resolved by fully resolving the objections and comments which Don has submitted. Action: Perform the suggested remedy for each objection raised in the ballot submitted to the Austin Group by Don Cragun. _____________________________________________________________________________ comment Enhancement Request Number 11 ieee.balloter BUG in P1003.1/D4 (rdvk# 207) [a.josey@xopen.org_969962263.3123_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: The final document should be that approved by the Austin Group Action: Synchronize with the Austin Group [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 12 ieee.balloter BUG in P1003.1/D4 (rdvk# 206) [don.cragun@eng.sun.com_969895495.25710_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Due to the hassle of having to create XML to submit ballot comments directly to IEEE, I have submitted bulk objections, comments, and editorial comments directly to the Austin Group aliases for this ballot. Action: This objection can be satisfied by resolving all of the objections I have submitted to the Austin Group aliases. _____________________________________________________________________________ objection Enhancement Request Number 13 ieee.balloter BUG in P1003.1/D4 (rdvk# 205) [keld@rap.dk_969961096.3014_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I refer to our comments to the Austin group. If these are resolved satisfactorily, the vote will be changed to "yes" Action: _____________________________________________________________________________ comment Enhancement Request Number 14 ieee.balloter BUG in P1003.1/D4 (rdvk# 202) [ajosey@opengroup.org_969889560.24660_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I recommend that the final approved draft be the same at the produced by the Austin Group Action: As above, synchronize the final draft. _____________________________________________________________________________ objection Enhancement Request Number 15 ieee.balloter BUG in P1003.1/D4 (rdvk# 198) [andrewr@eng.sun.com_969551206.29507_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections that Don Cragun has submitted tothe Austin Group in aardvark format and fully support those objections. My IEEE ballot objection can be resolved by fully resolving Don's objections. Action: For each objection Don submitted to the Austin Group inaardvark format, perform the action designated in the "Action:" aardvark field. _____________________________________________________________________________ editorial Enhancement Request Number 16 ieee.balloter BUG in P1003.1/D4 (rdvk# 194) [l.johnson@computer.org_969282990.22532_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Various identifiers exist on every page (including the running header and footer) to help work out where you are. The editors will discuss this with the submitter. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: There needs to be some sort of identifier of the section on each page. It is very difficult to find a section you need. Action: If you plan to continue having multiple sections 1, 2 , 3, etc, then you should use the following format: IV 3.2.1 2987 means book 4, section 3.2.1, page 2987 Other formats would be acceptable, as long as I know what section I am in. _____________________________________________________________________________ objection Enhancement Request Number 17 ieee.balloter BUG in P1003.1/D4 (rdvk# 201) [donnte@microsoft.com_969662953.12221_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_indiv_ballot_comments Reject_____ Rationale for rejected or partial changes: This was covered by considering the individual comments. _____________________________________________________________________________ Page: 0 Line: all Section: all Problem: I have submitted over 100 technical comments directly to the Austin group, which I support here. In addition, I attach three general comments about the document (which are also being sent to the Austing group) (in their format) so that they are directly visible to the IEEE balloting process. They are in Austin Group format, and include the suggested remedy inline. (The text is identical here and in what has been sent to the Austin Group.) > >@ Page all Line all Section all Objection [DST-179] > >Problem: >A significant amount of information from the base documents (the >ISO/IEEE standards of 1990-1999) has been lost editorially in the >current draft. I have balloted on this issue consistently that an >editorial pass needs to be made to restore this material, and I have >provided specific instances for correction as I find them. However, the >specific task of restoring the document's content (that was not >intentionally changed as authorized by the PAR) has not been performed. >Consequently, I believe that the PAR has not been met. > >The loss takes many forms, but two deserve specific mention: * >Rationale, introductory material, and the like have been dropped. > Specifically observed to be missing in this draft is the list of > omitted Commands and why they were omitted, and the 1003.1 > introduction that contains the critical "Interface, not > Implementation" discussion. >* Many of the normative "shall" statements were converted to active > verbs, losing their normative force. POSIX has always been weak in > this regard, and this regression is only to the detriment of the > standard. > >Before proceeding further with the formal ballot process, the editorial >problems need to be fixed. > >Action: >Restore all missing text and proper normative phrasing of requirements. >Attemt to (within the constraints of the new, and truly improved, order) >restore the other editorial strengths of the the originals. > >@ Page all Line all Section all Objection [DST-180] > >Problem: >This is a huge document. It runs to about 3500 pages, or well over 8 >inches in thickness. It is simply impossible to review the document, >particularly in light of the editorial problems, in even the two months >that have been given for it. (That requires careful, thorough reading >at the rate of over 50 pages a day, every day, for the two month >period.) That is not practical, particularly if one has other >responsibilities, and does not contribute to the quality of the standard >in the least. > >However, I recognize that it is desireable to complete this work as >quickly as possible, and in practice that most balloters will >procrastinate given a long ballot period. > >Related to this is simply fatigue: it is clear based simply on the >number of objections that the commands and utilities volume and the >rationale are not getting good coverage, and that (except for certain >specialty areas such as pthreads) that the front of the System >Interfaces gets more review than the back. > >Having a document which is of lesser quality than the documents >it revises is in no-one's interest. > >Action: >(I followed roughly the plan outlined below for this ballot cycle, >it did help a bit as I do have better coverage of the Rationale >and Commands and Utilities than I otherwise would.) > >Break the document up into "one month" sized chunks, and ballot >them in successive months, in the following order. The whole >document, not just changes, should remain open for comment during >the first such cycle, to assure that the thorough review required >does in fact happen at least once. (To be clear: the ballot period >for one piece would close the day before the ballot period for the >next one appears; the draft of that one piece should have been >distributed electronlically a few days before, so those who prefer >paper copies can get them printed.) > >XRAT (which has gotten far too little coverage) >XBD (because it's so basic to everything else) >XCU M-Z >XCU A-M >XSH Q-Z >XSH H-P >XSH A-G > >Repeat in this order, but as the number of changes drops, make the >chunks larger, but never less than 3, so that a piece can be in >the editors hands, another in balloting, and the third in ballot >review, continuously. (That is, until the number of changes required >to do the whole document can be reviewed in two weeks or so, the >standard recirculation period.) > >This is good for the editors, in that they do not have to produce >all 3500 pages at the same time, and the ballot resolution can >proceed (at least that part that can be done by email) in parallel >with the balloting.) (Since resolution starts earlier (because >there's a shorter delay in preparation of the first piece) and >resolution proceeds in parallel, the end of the cycle appears to >occur at about the same time as it would in a single "big batch".) > >@ Page all Line all Section all Objection [DST-181] > >Problem: >As indicated by the editor, revision bars were not always applied >accurately. In a document of this size, as the balloting cycle >narrows down on the number of open issues, it is desireable to have >shorter ballot cycles. However, that is impossible if the revision >bars are not accurate, because the whole document must be reread >each time. (Not that that's all bad, but...) > >Action: >As a matter of policy, if a change is made to the document, the change >is considered open for further balloting (by IEEE narrowing-down rules) >until such time that it is accurately marked with revison bars, plus >one draft. (That is, if an unmarked change is discovered in the >"last" ballot cycle, the unmarked item is still open for objection. >However, once an item has been marked, it has been exposed and the >usual rules apply.) > > >Action: >Imbedded in the Comment > > Action: See problem. _____________________________________________________________________________ objection Enhancement Request Number 18 ieee.balloter BUG in P1003.1/D4 (rdvk# 200) [damico@eng.sun.com_969679345.13124_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections that Don Cragun has submitted to the Austin Group in aardvark format and fully support those objections. My IEEE ballot objection can be resolved by fully resolving Don's objections. Action: For each objection Don submitted to the Austin Group in aardvark format, perform the action designated in the "Action:" aardvark field. _____________________________________________________________________________ objection Enhancement Request Number 19 ieee.balloter BUG in P1003.1/D4 (rdvk# 199) [J.Isaak@Computer.org_969486364.22831_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Out of scope. This change is possibly detrimental to embedded systems, and really is a profiling issue. This is a solution to something that has never previously been stated as a problem. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: An essential aspect of POSIX/UNIX systems is support for multiple user ID's. I belive we should add two requirements and one suggestion to address this in a way that is consistent with the work so far. 1) require support for at least xx user id's (I'd go for 16k, but willing to go with any number greater than 16) 2) require that vendors document the privilaged administrative function required to set user ID at both the API and shell level. 3) Recommend that user id's support a full 64 bit field (This allows large organizations to have unique user id's over many systems with out the need for re-use ... consider a college with 20K new students each year....) Action: IF there is general acceptance for this approach we can add additional wording (I belive that the functionallity defined is already present in most if not all vendors systems, including documentation, so this should not require an changes in vendor systems or vendor documentation.) _____________________________________________________________________________ comment Enhancement Request Number 20 ieee.balloter BUG in P1003.1/D4 (rdvk# 197) [beh@peren.com_969463247.18079_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: The final version of this document should correspond to that being produced by the Austin Group. Action: see comment _____________________________________________________________________________ objection Enhancement Request Number 21 ieee.balloter BUG in P1003.1/D4 (rdvk# 196) [prindle@ieee.org_967665364.2684_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections which I have submitted to Open Group in aardvark format and fully support those objections. My IEEE ballot objections can be resolved by fully resolving those objections. Action: For each objection submitted to the Open Group in aardvark format, perform the action designated in the "Action:" aardvark field. _____________________________________________________________________________ objection Enhancement Request Number 22 ieee.balloter BUG in P1003.1/D4 (rdvk# 195) [David.Butenhof@compaq.com_969384163.6106_ieee] Wed Sep 27 16:11:28 BST 2000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have reviewed the objections which I have submitted to Open Group in aardvark format and fully support those objections. My IEEE ballot objections can be resolved by fully resolving those objections. Action: Resolve the Austin group aardvark objections I have submitted, which are identifiable by the tag pattern "drb.xshd4.*" and "drb-xbdd4-*". _____________________________________________________________________________ Objection Enhancement Request Number 23 donnte@microsoft.com Bug in XBDd4 OVERALL (rdvk# 103) [DST-181] Fri, 22 Sep 2000 15:50:33 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The Change bars utility has been reworked for D5. This will resolve this issue. _____________________________________________________________________________ Page: all Line: all Section: all Problem: As indicated by the editor, revision bars were not always applied accurately. In a document of this size, as the balloting cycle narrows down on the number of open issues, it is desireable to have shorter ballot cycles. However, that is impossible if the revision bars are not accurate, because the whole document must be reread each time. (Not that that's all bad, but...) Action: As a matter of policy, if a change is made to the document, the change is considered open for further balloting (by IEEE narrowing-down rules) until such time that it is accurately marked with revison bars, plus one draft. (That is, if an unmarked change is discovered in the "last" ballot cycle, the unmarked item is still open for objection. However, once an item has been marked, it has been exposed and the usual rules apply.) _____________________________________________________________________________ Objection Enhancement Request Number 24 donnte@microsoft.com Bug in XBDd4 OVERALL (rdvk# 101) [DST-179] Fri, 22 Sep 2000 15:50:33 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept as marked: We have identified the specifics below and also we have embarked on another concentrated effort of shallifying the normative text, this has been done by pattern matching text in the draft looking for common constructs that should include the use of "shall" to express requirements. This will extend the use of shall over the original volumes and make the draft more consistent. Some further difference checks of chapters between original text and the revision is also being done. _____________________________________________________________________________ Page: all Line: all Section: all Problem: A significant amount of information from the base documents (the ISO/IEEE standards of 1990-1999) has been lost editorially in the current draft. I have balloted on this issue consistently that an editorial pass needs to be made to restore this material, and I have provided specific instances for correction as I find them. However, the specific task of restoring the document's content (that was not intentionally changed as authorized by the PAR) has not been performed. Consequently, I believe that the PAR has not been met. The loss takes many forms, but two deserve specific mention: * Rationale, introductory material, and the like have been dropped. Specifically observed to be missing in this draft is the list of omitted Commands and why they were omitted, and the 1003.1 introduction that contains the critical "Interface, not Implementation" discussion. * Many of the normative "shall" statements were converted to active verbs, losing their normative force. POSIX has always been weak in this regard, and this regression is only to the detriment of the standard. Before proceeding further with the formal ballot process, the editorial problems need to be fixed. Action: Restore all missing text and proper normative phrasing of requirements. Attemt to (within the constraints of the new, and truly improved, order) restore the other editorial strengths of the the originals. _____________________________________________________________________________ Objection Enhancement Request Number 25 donnte@microsoft.com Bug in XBDd4 OVERALL (rdvk# 102) [DST-180] Fri, 22 Sep 2000 15:50:33 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This was discussed with the objector in the workplan discussion. Some revised sections will be circulated in this way (maths,printf functions and certain utilities). See the meeting minutes for the full disposition. _____________________________________________________________________________ Page: all Line: all Section: all Problem: This is a huge document. It runs to about 3500 pages, or well over 8 inches in thickness. It is simply impossible to review the document, particularly in light of the editorial problems, in even the two months that have been given for it. (That requires careful, thorough reading at the rate of over 50 pages a day, every day, for the two month period.) That is not practical, particularly if one has other responsibilities, and does not contribute to the quality of the standard in the least. However, I recognize that it is desireable to complete this work as quickly as possible, and in practice that most balloters will procrastinate given a long ballot period. Related to this is simply fatigue: it is clear based simply on the number of objections that the commands and utilities volume and the rationale are not getting good coverage, and that (except for certain specialty areas such as pthreads) that the front of the System Interfaces gets more review than the back. Having a document which is of lesser quality than the documents it revises is in no-one's interest. Action: (I followed roughly the plan outlined below for this ballot cycle, it did help a bit as I do have better coverage of the Rationale and Commands and Utilities than I otherwise would.) Break the document up into "one month" sized chunks, and ballot them in successive months, in the following order. The whole document, not just changes, should remain open for comment during the first such cycle, to assure that the thorough review required does in fact happen at least once. (To be clear: the ballot period for one piece would close the day before the ballot period for the next one appears; the draft of that one piece should have been distributed electronlically a few days before, so those who prefer paper copies can get them printed.) XRAT (which has gotten far too little coverage) XBD (because it's so basic to everything else) XCU M-Z XCU A-M XSH Q-Z XSH H-P XSH A-G Repeat in this order, but as the number of changes drops, make the chunks larger, but never less than 3, so that a piece can be in the editors hands, another in balloting, and the third in ballot review, continuously. (That is, until the number of changes required to do the whole document can be reviewed in two weeks or so, the standard recirculation period.) This is good for the editors, in that they do not have to produce all 3500 pages at the same time, and the ballot resolution can proceed (at least that part that can be done by email) in parallel with the balloting.) (Since resolution starts earlier (because there's a shorter delay in preparation of the first piece) and resolution proceeds in parallel, the end of the cycle appears to occur at about the same time as it would in a single "big batch".) _____________________________________________________________________________ editorial Enhancement Request Number 26 y.hosang@ieee.org Bug in XBDd4 (rdvk# 221) {ieee_editrev.1} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 3 Section: all Problem: References to IEEE standards incorrect Action: Change "Std." throughout to "Std" (no period) _____________________________________________________________________________ Editorial Enhancement Request Number 27 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 64) [DST-9] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add at 17: 4. Extended rationale that did not fit well into the rest of the document structure, containing historical information concerning the contents of IEEE Std 1003.1-200x and why features were included or discarded by the standard developers, is included in the Rationale (Informative) volume of IEEE Std 1003.1-200x. Change at 7: three->four. _____________________________________________________________________________ Page: 1 Line: 7 Section: Introduction Problem: There are 4 parts; the rationale, too. Action: Add at 17: 4. A non-normative extended rationale covering details that do not fit well into the rest of the document structure, explaining why certain choices were made, and as guideance to future writers and users of the standard. Change at 7: three->four. _____________________________________________________________________________ Comment Enhancement Request Number 28 Keld Simonsen bug in XBDd4 (rdvk# 244) [KS-1] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: AAM Leave the current wording as is for now (done by strings). We expect WG15 to action this in their comments against the draft and will change the strings at that time. _____________________________________________________________________________ Page: 1 Line: 7 Section: Introduction Problem: The specification refers to IEEE standards, not to an ISO standard. Action: Change all occurances of "IEEE Std. 1003.1-200x" to "this International Standard". Change all other IEEE references to ISO/IEC references. _____________________________________________________________________________ editorial Enhancement Request Number 29 y.hosang@ieee.org Bug in XBDd4 (rdvk# 222) {ieee_editrev.2} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1-2 Line: 32,39 Section: 1.1 Problem: I assume that all these drafts will be approved before the publication of the document, therefore the approved standard designation will be used. If not, the draft numbers and dates need to be included and a copy of the drafts submitted to me for my files. Action: Update later to approved standards or submit copies of the drafts to me. [Ed recommendation: Accept as marked. If there are any recent approvals please let us know] _____________________________________________________________________________ Comment Enhancement Request Number 30 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 60) [DST-5] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: xix Line: 705 Section: Preface Problem: There's no mention of XRAT. Action: At 705: * Rationale (non-normative). [Ed recommendation: Accept as marked Add At 705: * Rationale (Informative). ] _____________________________________________________________________________ Objection Enhancement Request Number 31 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 61) [DST-6] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Donn is correct there are some change bar problems in this draft, some of which are noted in the reviewers notes. The change barring tool has been redone for D5. For those who are only looking at change bar'd text, please note the following, in general, you should assume that not all tables and code fragments are change bar'd (they should be in D5). To address Donn's specific issue for the main text of D4, I noted the following pages where change barring was erroneously switched off globally XBDd4 page 155-166 XSHd4 page 494-515 XCUd4 page 2957-2963 We are able to diffmk between any draft, i.e. d1->d4, d2-d4, d3->d4 etc, however they are not being used for any purpose yet. We do not hand produce the diffmks as in other POSIX drafts all marking has to be done via automated tools. _____________________________________________________________________________ Page: xx Line: 746 Section: Preface Problem: This is a two part item, one trivial one very serious. Trivial: line 746 changed. There is no revision bar. Serious: a revision bar was missed. How do I know there are not others? For those who are keying off revision bars, this is an alert that they may not have seen all changes. Action: Trivial: none. It doesn't really matter in this case. Serious: All revisions between D3 and D4 that were NOT marked in D4 need to be marked in D5, so they can be properly reviewed. (By those who only look at revisions). _____________________________________________________________________________ Editorial Enhancement Request Number 32 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 62) [DST-7] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove normative refs from frontmatter (xxiv) and add pointer to normative text version of normative refs. _____________________________________________________________________________ Page: xxiv Line: 801 Section: Referenced Problem: This *is* XBD, so we don't have to worry about sync with it. Action: Since the normative references are required in chapter 1, there's no need to repeat them here. Informative references have a specific ISO-mandated place (I believe Annex 1, but I'm not sure), and should go there. Delete this section, so there's only one to keep up. (This action will also clear my objection DST-8, which is an illegal normative reference to a (to be) obsoleted version.) _____________________________________________________________________________ Objection Enhancement Request Number 33 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 63) [DST-8] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This section will be further reworked as per the reviewers note, also see ERN32. _____________________________________________________________________________ Page: xxiv Line: 836 Section: Referenced Problem: Illegal reference (per ISO) to an obsoleted document (which is "us" if we update it to refer to the current one, so nonsensical). Action: Delete. (But see DST-7, suggesting we delete the section.) _____________________________________________________________________________ editorial Enhancement Request Number 34 pete.forman@westgeo.com Bug in XBDd4 1.1 Scope (rdvk# 87) {PWF20000919/2} Tue, 19 Sep 2000 10:53:49 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2 Line: 65 Section: 1.1 Problem: This paragraph lists legacy interfaces not carried forward from XSH 5, in particular those declared in regexp.h. The interface step() has been omitted from the list. Action: Insert an entry for "step()" in the list on line 65. _____________________________________________________________________________ editorial Enhancement Request Number 35 y.hosang@ieee.org Bug in XBDd4 (rdvk# 223) {ieee_editrev.3} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 117 Section: all Problem: References to clauses and subclauses are incorrect. The ISO Directive suggests references to main clauses as Clause x, but references to subclauses should contain the numbers only (see 5.1.2 of ISO Manual). Action: Delete "Subclause" or "Clause" before cross-references to subclauses. _____________________________________________________________________________ editorial Enhancement Request Number 36 y.hosang@ieee.org Bug in XBDd4 (rdvk# 224) {ieee_editrev.4} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 5 Line: 133 Section: all Problem: Subclauses should not begin on a new page. We need to avoid pages with large spaces on them. Action: Run in text for subclauses. [Ed recommendation: Accept as marked. We can do this for these front sections, but not for the manual pages.] _____________________________________________________________________________ Objection Enhancement Request Number 37 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 65) [DST-10] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 6 Line: 166, Section: Normative Problem: Remove the self-references completely (since we can't make normative reference to old versions, per ISO). (This doesn't obviate other corrections, but should simplify them.) Action: Remove. [Ed recommendation: Accept as marked The reviewers note on line 142-144 states that this section will be updated. Part of the update will be removal of lines 166-169] _____________________________________________________________________________ editorial Enhancement Request Number 38 y.hosang@ieee.org Bug in XBDd4 (rdvk# 225) {ieee_editrev.5} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 7 Line: 177,183 Section: 1.2 Problem: References to ISO/IEC standards adopted from IEEE standards should include the IEEE designation (see ISO/IEC 9945-1) Action: Include IEEE designation. _____________________________________________________________________________ editorial Enhancement Request Number 39 y.hosang@ieee.org Bug in XBDd4 (rdvk# 226) {ieee_editrev.6} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 15 Line: 502 Section: 1.5.1 Problem: Reference to TPS is incorrect? Action: Change TPS to TSA _____________________________________________________________________________ editorial Enhancement Request Number 40 y.hosang@ieee.org Bug in XBDd4 (rdvk# 227) {ieee_editrev.7} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 17 Line: 550 Section: 1.5.1 Problem: Reference given does not seem to indicate a section that is completely shaded. Action: Check cross-reference (use 2.1.4?) [Ed recommendation: Accept Point the reference to 2.1.4] _____________________________________________________________________________ editorial Enhancement Request Number 41 y.hosang@ieee.org Bug in XBDd4 (rdvk# 228) {ieee_editrev.8} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 17 Line: 564 Section: all Problem: Possible to make shaded paragraph rectangular? Action: Fix shading [Ed recommendation: Accept as marked We can attempt it, but in general All shading , page breaking and other minor alignment changes will not be attempted until the final proof draft. Many of the shading behavior is postscript related - if there are volunteers to work on this item....] _____________________________________________________________________________ editorial Enhancement Request Number 42 y.hosang@ieee.org Bug in XBDd4 (rdvk# 229) {ieee_editrev.9} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_43 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 17 Line: 574, Section: 1.5.2 Problem: Code1 and code2 should be replaced with the appropriate codes. Is there still a problem with fit? A code for each permutation is needed? Action: Change code1 to ADV (MF|SHM) and delete notation from main text. Change code2 to MF|SHM|MPR and delete notation from main text. _____________________________________________________________________________ Editorial Enhancement Request Number 43 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 66) [DST-11] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use codes MC1 and MC2, and add these to the codes section (1.5), _____________________________________________________________________________ Page: 17 Line: 574, Section: 1.5.2 Problem: "code1" and "code2" are undefined. I presume these are intended to actually be "ADV (MF|SHM)" and "MF|SHM|MPR", respectively. Action: Fix, either as above or as intended. _____________________________________________________________________________ editorial Enhancement Request Number 44 y.hosang@ieee.org Bug in XBDd4 (rdvk# 230) {ieee_editrev.10} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 20 Line: 629 Section: 2.1.2 Problem: "paragraph" should be plural Action: Change to "preceding paragraphs" _____________________________________________________________________________ editorial Enhancement Request Number 45 y.hosang@ieee.org Bug in XBDd4 (rdvk# 231) {ieee_editrev.11} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change required,we checked the list and this is an optional TSF reqt. _____________________________________________________________________________ Page: 21 Line: 663 Section: 2.1.3.1 Problem: Should _POSIX_DEVICE_SPECIFIC_R be included? Action: Check list. _____________________________________________________________________________ objection Enhancement Request Number 46 prindle@voicenet.com (rdvk# 104) Mon, 25 Sep 2000 10:05:14 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Raw Sockets is being added in this draft. Ensure we have an option for RAW Sockets in section 1.5.1 These additions should be shaded and marked RAW. Add SOCK_RAW to 2.10.6 line 2589, changing "three" to "four" Add new para at end of 2.10.6 The SOCK_RAW socket type is similar to the SOCK_DGRAM type. It differs in that it is normally used with communication providers that underly those used for the other socket types. For this reason the creation of a socket with type SOCK_RAW shall require appropriate privilege. The format of datagrams sent and received with this socket type generally include specific protocol headers, and the formats are protocol-specific. Add SOCK_RAW to p 1701 recvfrom line 37151 (adding to list of socket types described) Add to page 390 line 13048 SOCK_RAW Raw Protocol Interface Add to netinet/in.h p 315 line 10491 IPPROTO_RAW RAW IP Packets Protocol When a socket is created in the Internet family with a protocol value of zero, the implementation shall use the protocol listed below for the type of socket created. Socket type Protocol SOCK_STREAM TCP SOCK_DGRAM UDP SOCK_RAW protocol number IPPROTO_RAW (shading only here) SOCK_SEQPACKET unspecified Shading on A raw interface to IP is available by creating an Internet socket of type SOCK_RAW. The default protocol for type SOCK_RAW shall be identified in the IP header with the value IPPROTO_RAW. Applications should not use the default protocol when creating a socket with type SOCK_RAW, but should identify a specific protocol by value. The ICMP control protocol is accessible from a raw socket by specifying a value of IPPROTO_ICMP for protocol. Rationale: A raw socket allows privileged users direct access to a protocol, for example raw access to the IP and ICMP protocols is possible through raw sockets. Raw sockets are intended for knowledgeable applications that wish to take advantage of some protocol feature not directly accessible through the other sockets interfaces. _____________________________________________________________________________ Page: 22 Line: 701 Section: 2.1.3.1 [prindle.xbd-1] Problem: The option symbol _POSIX_RAW_SOCKETS does not represent an option that is specified anywhere in XSH. In particular, SOCK_RAW is not specified as a socket type on the socket() man page. Action: Remove this line. _____________________________________________________________________________ editorial Enhancement Request Number 47 y.hosang@ieee.org Bug in XBDd4 (rdvk# 232) {ieee_editrev.12} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 24 Line: 802-805 Section: 2.1.4.2 Problem: Vertical lines off Action: Fix placement of vertical lines [Ed recommendation: Accept as marked. This is a known problem with the change barring and will not appear in the final document.] _____________________________________________________________________________ editorial Enhancement Request Number 48 y.hosang@ieee.org Bug in XBDd4 (rdvk# 233) {ieee_editrev.13} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 24 Line: 806 Section: 2.1.4.2 Problem: No OP or PI codes found in 1.5.1 Action: Verify that codes listed are correct. [Ed recommendation: Accept as marked. We have checked the draft and will remove codes PI and OP (inc from rationale)] _____________________________________________________________________________ Objection Enhancement Request Number 49 adjg@eng.sun.com BUG in XBDd4 (rdvk# 56) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 26 Line: 860-1 Section: conformance Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), and getipnodebyname(). _____________________________________________________________________________ editorial Enhancement Request Number 50 y.hosang@ieee.org Bug in XBDd4 (rdvk# 234) {ieee_editrev.14} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 26 Line: 890 Section: 2.1.5.1 Problem: Footnotes should appear on the same page as their citations. Action: Fix footnote placement. [Ed recommendation: Accept as marked We will fix up this sort of problem in the final proof] _____________________________________________________________________________ Comment Enhancement Request Number 51 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 67) [DST-12] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make it non country specific change line 917 to "Due to export restrictions on the decoding algorithm in some countries, implementations may be..." _____________________________________________________________________________ Page: 27 Line: 917 Section: 2.1.5.2 Problem: The law w.r.t. US export of encryption keeps changing. Action: 1) Add "Reviewers Note" to that effect. 2) Update as appropriate if the law changes. It'd be nice to require the same thing worldwide. _____________________________________________________________________________ objection Enhancement Request Number 52 gwinn@res.ray.com Bug in XBDd4 _POSIX_RAW_SOCKETS (rdvk# 189) {JMG-3} Tue, 26 Sep 2000 23:58:28 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_46 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 29 Line: 701 Section: _POSIX_RAW_SOCKETS Problem: The 1003.1g-2000 socket type SOCK_RAW is mentioned here, but appears nowhere else in the present draft, leaving out a necessary socket type I'd like to be able to let go of 1003.1g, and absence of raw sockets in XNS is my main holdup. Otherwise, we may see mandates calling out 1003.1-200x plus 1003.1g-2000, a real nuisance for all. In 1003.1g, Section 5.1.4 "Socket Types" on (pdf) pages 134-135, lines 49-93, defines among other kinds SOCK_RAW. The definition text (lines 88-93) follows: "The SOCK_RAW socket type is similar to the SOCK_DGRAM type. It differs in that it is normally used with communication providers that underly those used for the other socket types. For this reason the creation of a socket with type SOCK_RAW shall require appropriate privilege. The format of datagrams sent and received with this socket type generally include specific protocol headers, and the formats are protocol-specific." Action: Add text as appropriate to implement the raw sockets option. The necessary text may be taken from 1003.1g-2000. The following locations in P1003.1g/d6.6 (the final draft) contain relevant text. All page numbers are those of pdf, not what appear on the actual pages, for convenience. The list: pdf page 145, lines 49-93; p.150, 344-250; p.161, 633; p.180, 1353; p.183, 1442; p.278, 2055; p.280, 2182; p.284, 2316-2350. The mappings to ISO have been omitted. Some of these cites may be too detailed for 1003.1, judging by the level of description of the other socket types. _____________________________________________________________________________ editorial Enhancement Request Number 53 y.hosang@ieee.org Bug in XBDd4 (rdvk# 235) {ieee_editrev.15} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Editors will fix appropriately _____________________________________________________________________________ Page: 29 Line: 1027 Section: 2.1.5 Problem: Should "symbols" be replaced by "following options" as on line 1017? Action: Replace "symbols" or fix intro paragraph to refer to list (lines 1029-1031). _____________________________________________________________________________ editorial Enhancement Request Number 54 y.hosang@ieee.org Bug in XBDd4 (rdvk# 236) {ieee_editrev.16} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept for wcswcs(), however due to the inclusion of the networking materials in the base functionality, h_errno now becomes obsolescent rather than LEGACY and so is not listed here. _____________________________________________________________________________ Page: 32 Line: 1111-1112 Section: 2.1.5 Problem: h_errno and wcswcs() missing from list of functions or headers marked LEGACY (not sure if h_errno is applicable). Action: Include h_errno and wcswcs() in list, if appropriate. _____________________________________________________________________________ editorial Enhancement Request Number 55 y.hosang@ieee.org Bug in XBDd4 (rdvk# 237) {ieee_editrev.17} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 33 Line: 1180 Section: 2.1.6.1 Problem: SH not defined on page 13. Action: Define SH [Ed recommendation: Accept as marked. The _POSIX_SHELL symbol is not an option, it has a value of always 1. See unistd.h page 440. Remove lines 1180-1183, and remove the SH marker and unshade from the entry in unistd.h on page 440] _____________________________________________________________________________ editorial Enhancement Request Number 56 y.hosang@ieee.org Bug in XBDd4 (rdvk# 238) {ieee_editrev.18} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 36 Line: 1292 Section: 2.1.6.2 Problem: Note should be in smaller font size than text. Action: Check Note font size throughout. _____________________________________________________________________________ editorial Enhancement Request Number 57 y.hosang@ieee.org Bug in XBDd4 (rdvk# 239) {ieee_editrev.19} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We are reworking the change bar tool for D5. Change bar issues will not be present in the final draft _____________________________________________________________________________ Page: 37 Line: 1331-1340 Section: 2.1.6.2 Problem: Vertical lines Action: Fix placement of vertical lines. _____________________________________________________________________________ editorial Enhancement Request Number 58 y.hosang@ieee.org Bug in XBDd4 (rdvk# 240) {ieee_editrev.20} Wed, 27 Sep 2000 14:56:20 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 38 Line: 1360 Section: 2.2.1 Problem: ISO C standard not previously defined in references. Action: Place abbreviation beside reference in 1.3 (also for C99). [Ed recommendation: Accept as marked for lines 1359-1363 use ISO/IEC 9899:1999 string] _____________________________________________________________________________ editorial Enhancement Request Number 59 y.hosang@ieee.org Bug in XBDd4 (rdvk# 254) {ieee_editrev.22} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 38 Line: 1365 Section: 2.2.1 Problem: Is 200xxxL correct? Action: Replace with 200xmmL? _____________________________________________________________________________ editorial Enhancement Request Number 60 y.hosang@ieee.org Bug in XBDd4 (rdvk# 255) {ieee_editrev.23} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 40 Line: 1420-1421 Section: 2.3 Problem: Transition missing? Action: Check for correct meaning. [Ed recommendation: Accept as marked. We will remove the end of the sentence ",C Language....).] _____________________________________________________________________________ editorial Enhancement Request Number 61 y.hosang@ieee.org Bug in XBDd4 (rdvk# 257) {ieee_editrev.25} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 41 Line: 1434 Section: Definitions Problem: Intro sentence needed. Action: Add "For the purposes of this International Standard, the terms and definitions given in Chapter 3 apply." _____________________________________________________________________________ editorial Enhancement Request Number 62 y.hosang@ieee.org Bug in XBDd4 (rdvk# 256) {ieee_editrev.24} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 41 Line: 1451 Section: Definitions Problem: Extra space at bottom of pages. Action: Fill pages throughout. [Ed recommendation: Accept as marked This will be dealt with in the final proof] _____________________________________________________________________________ Editorial Enhancement Request Number 63 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 105) [DWC-683] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 42 Line: 1460 Section: 3.8 Problem: (alert: character) The term is defined (XBD6d4, P42, L1463-1467) to be a synonym for "alert character". Therefore, the phrase " character" expands to "alert character character". Action: Change " character" on P42, L1460 to "". ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 64 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 106) [DWC-684] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 42 Line: 1465 Section: 3.9 Problem: (alert character: character) The term is defined (XBD6d4, P42, L1463-1467) to be a synonym for "alert character". Therefore, the phrase " character" expands to "alert character character". Action: Change " character" on P42, L1465 to "". ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 65 y.hosang@ieee.org Bug in XBDd4 (rdvk# 258) {ieee_editrev.26} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 42 Line: 1475 Section: 3.11 Problem: Need period at end of sentence. Action: Add period. See also: p. 60 line 1901 section 3.111 _____________________________________________________________________________ editorial Enhancement Request Number 66 y.hosang@ieee.org Bug in XBDd4 (rdvk# 259) {ieee_editrev.27} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 42 Line: 1476 Section: 3.11 Problem: Usually avoid use of section character. Action: Change to "Section B3." [Ed recommendation: Accept will check throughout] _____________________________________________________________________________ editorial Enhancement Request Number 67 y.hosang@ieee.org Bug in XBDd4 (rdvk# 260) {ieee_editrev.28} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the term at 3.22 _____________________________________________________________________________ Page: 44 Line: 1522 Section: 3.22 Problem: Missing info Action: Include definition. _____________________________________________________________________________ Editorial Enhancement Request Number 68 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 107) [DWC-685] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 47 Line: 1573 Section: 3.38 Problem: (backspace character: character) The term is defined (XBD6d4, P47, L1568-1569) to be a synonym for "backspace character". Therefore, the phrase " character" expands to "backspace character character". Action: Change " character" on P47, L1573 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 69 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 108) [DWC-686] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 47 Line: 1576 Section: 3.38 Problem: (backspace character: character) The term is defined (XBD6d4, P47, L1568-1569) to be a synonym for "backspace character". Therefore, the phrase " character" expands to "backspace character character". Action: Change " character" on P47, L1576 to "". _____________________________________________________________________________ editorial Enhancement Request Number 70 y.hosang@ieee.org Bug in XBDd4 (rdvk# 261) {ieee_editrev.29} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This changes the meaning, the sentence is correct as is. _____________________________________________________________________________ Page: 51 Line: 1668 Section: 3.60 Problem: Need plural queues. Action: Change "Two types of batch queue" to "Two types of batch queues" at the beginning of the sentence. _____________________________________________________________________________ editorial Enhancement Request Number 71 y.hosang@ieee.org Bug in XBDd4 (rdvk# 262) {ieee_editrev.301} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1675 Section: 3.61 Problem: Repeated word okay (batch batch queue)? Action: Delete extra batch? _____________________________________________________________________________ editorial Enhancement Request Number 72 y.hosang@ieee.org Bug in XBDd4 (rdvk# 263) {ieee_editrev.31} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 52 Line: 1689 Section: 3.65 Problem: Not structured as a definition. Action: Change to "The action of resuming the processing" or something similar. _____________________________________________________________________________ editorial Enhancement Request Number 73 y.hosang@ieee.org Bug in XBDd4 (rdvk# 264) {ieee_editrev.32} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1721 Section: 3.74 Problem: Not structured as a definition. Action: Change to "The process of assigning " or something similar. See also: p. 54 line 1733 section 3.78; p. 79 line 2324 section 3.222 _____________________________________________________________________________ Editorial Enhancement Request Number 74 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 110) [DWC-688] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1724 Section: 3.75 Problem: (blank character: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " character" on P53, L1724 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 75 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 142) [DWC-720] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1725 Section: 3.75 Problem: (blank character: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P53, L1725 to ".". _____________________________________________________________________________ Editorial Enhancement Request Number 76 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 128) [DWC-706] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1727 Section: 3.76 Problem: (blank line: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character;" on P53, L1727 to ";". _____________________________________________________________________________ Editorial Enhancement Request Number 77 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 111) [DWC-689] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1727 Section: 3.76 Problem: (blank likne: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P53, L1727 to "s". _____________________________________________________________________________ Objection Enhancement Request Number 78 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 68) [DST-13] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 55 Line: 1753 Section: 3.83 Problem: "Break value" isn't used in the rest of the document. (I didn't check XCU, but if it's used there, it shouldn't be, on principle!) Action: Remove item. [Ed recommendation: Accept (this was originally here to support brk(), sbrk()] _____________________________________________________________________________ editorial Enhancement Request Number 79 y.hosang@ieee.org Bug in XBDd4 (rdvk# 265) {ieee_editrev.33} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 55 Line: 1756-1757 Section: 3.84 Problem: RFC 919 and 922 cited as bibliographical reference? Action: Cite in Bibliography? [Ed recommendation: Reject These are in the reference documents section, informative references] _____________________________________________________________________________ Editorial Enhancement Request Number 80 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 123) [DWC-701] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 56 Line: 1787-1788 Section: 3.88 Problem: (carriage return: character) The term is defined (XBD6d4, P56, L1785-1790) to be a synonym for "carriage-return character". Therefore, the phrase " character" expands to "carriage-return character character". Action: Change " character occurred. The character" on P56, L1787-1788 to " occurred. The ". _____________________________________________________________________________ editorial Enhancement Request Number 81 y.hosang@ieee.org Bug in XBDd4 (rdvk# 266) {ieee_editrev.34} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: spell out REs as Regular Expressions, change to "Range Expressions within Regular Expressions" _____________________________________________________________________________ Page: 58 Line: 1851 Section: 3.103 Problem: Should acronym be in parentheses? Action: Change to "used in range expressions (REs) and" _____________________________________________________________________________ editorial Enhancement Request Number 82 y.hosang@ieee.org Bug in XBDd4 (rdvk# 267) {ieee_editrev.35} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 59 Line: 1866 Section: 3.105 Problem: Strings that collate equally meant? Action: Change to "equally." _____________________________________________________________________________ Editorial Enhancement Request Number 83 jeffcope@microsoft.com (rdvk# 193) [Copeland-xbd-1] Tue, 26 Sep 2000 11:34:20 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team believes that accepting the proposed change would decrease consensus. _____________________________________________________________________________ Page: 59 Line: 1868 Section: 3.105 Problem: We've defined "collation sequence" but not "collation order". Action: Add another definition: Collation order: The relative order of presentation of the collating elements in the LC_COLLATE category specification. The collation order is used only to determine the content of (deprecated) range expressions such as "[a-j]". _____________________________________________________________________________ Editorial Enhancement Request Number 84 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 129) [DWC-707] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 66 Line: 2013 Section: 3.146 Problem: (empty line: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character;" on P66, L2013 to ";". _____________________________________________________________________________ editorial Enhancement Request Number 85 y.hosang@ieee.org Bug in XBDd4 (rdvk# 268) {ieee_editrev.36} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 66 Line: 2024 Section: 3.150 Problem: Acronyms in definitions should be spelled out at the first instance in each definition. Action: Spell out Basic Regular Expression (BRE) and Extended Regular Expression (ERE). See also: p. 78 line 2308 section 3.219 _____________________________________________________________________________ editorial Enhancement Request Number 86 y.hosang@ieee.org Bug in XBDd4 (rdvk# 269) {ieee_editrev.37} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change definition to "A locale specific method for counting and displaying years" _____________________________________________________________________________ Page: 67 Line: 2038 Section: 3.153 Problem: Alternative to what? Action: Expand definition to explain alternative. _____________________________________________________________________________ editorial Enhancement Request Number 87 y.hosang@ieee.org Bug in XBDd4 (rdvk# 270) {ieee_editrev.38} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 67 Line: 2050 Section: 3.156 Problem: Possible to rearrange definition to make it clearer? Action: Change to "To perform command search and execution actions, as defined in the Shell and Utilities volume of IEEE Std 1003.1-200x; see also Section 3.202 (on page 75)." _____________________________________________________________________________ Editorial Enhancement Request Number 88 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 72) [DST-17] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 68 Line: 2061 Section: 3.159 Problem: We have more than enough "worK expansions" already. I think this should be word expansion. Action: work->word. _____________________________________________________________________________ Editorial Enhancement Request Number 89 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 125) [DWC-703] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 73 Line: 2183 Section: 3.187 Problem: (form-feed character: character) The term is defined (XBD6d4, P73, L2181-2186) to be a synonym for "form-feed character". Therefore, the phrase " character" expands to "form-feed character character". Action: Change " character" on P73, L2183 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 90 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 126) [DWC-704] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 73 Line: 2184 Section: 3.187 Problem: (form-feed character: character) The term is defined (XBD6d4, P73, L2181-2186) to be a synonym for "form-feed character". Therefore, the phrase " character" expands to "form-feed character character". Action: Change " character" on P73, L2184 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 91 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 130) [DWC-708] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 74 Line: 2225 Section: 3.196 Problem: (incomplete line: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change "non- characters" on P74, L2225 to "non-s". _____________________________________________________________________________ Editorial Enhancement Request Number 92 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 131) [DWC-709] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 76 Line: 2270 Section: 3.207 Problem: (line: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change "non- characters plus a terminating character." on P76, L2270 to "non-s plus a terminating .". ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 93 y.hosang@ieee.org Bug in XBDd4 (rdvk# 271) {ieee_editrev.39} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change definition to "A period of time..." _____________________________________________________________________________ Page: 76 Line: 2272 Section: 3.208 Problem: Format as a definition. Action: Change to The wait _____________________________________________________________________________ editorial Enhancement Request Number 94 y.hosang@ieee.org Bug in XBDd4 (rdvk# 272) {ieee_editrev.40} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the term to be "Memory Mapped Files" (only) "A facility to allow applications to access files as part of the address space." _____________________________________________________________________________ Page: 78 Line: 2310 Section: 3.220 Problem: Is this one or two separate terms? Action: Separate terms "memory mapped files" and "shared memory objects" then cross reference one to the other if necessary. _____________________________________________________________________________ editorial Enhancement Request Number 95 y.hosang@ieee.org Bug in XBDd4 (rdvk# 253) {ieee_editrev.21} Sat, 30 Sep 2000 13:44:30 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The terms are all defined elsewhere, so just add xrefs _____________________________________________________________________________ Page: 78 Line: 2317-2318 Section: 3.221 Problem: Term used in its own definition. Action: Restate to give a description of the term "memory object." _____________________________________________________________________________ Editorial Enhancement Request Number 96 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 132) [DWC-710] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 82 Line: 2392 Section: 3.240 Problem: (newline character: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P82, L2392 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 97 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 109) [DWC-687] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 89 Line: 2570 Section: 3.284 Problem: (printable file: character) The term is defined (XBD6d4, P47, L1568-1569) to be a synonym for "backspace character". Therefore, the phrase " character" expands to "backspace character character". Action: Change " character," on P89, L2570 to ",". _____________________________________________________________________________ Editorial Enhancement Request Number 98 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 143) [DWC-721] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 101 Line: 2844 Section: 3.354 Problem: (space character: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change ". The character" on P101, L2844 to ". The ". _____________________________________________________________________________ Objection Enhancement Request Number 99 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 69) [DST-14] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 106 Line: 2986 Section: 3.386 Problem: If I remember correctly, it was concluded that the CSQ (which is as far as I can tell, not otherwise mentioned in the document) is an TOG only thing. Its mention here with no qualification that it is XSI (including the lack of any description) is confusing and misleading. To be clear: this is a dangling reference to an undefined term. Action: Either remove the reference to the CSQ, or shade it so it's clearly a TOG thing. (Or... provide an XSI shaded discussion of the CSQ) [Ed recommendation: Accept as marked. Delete the sentence at line 2986-2987: "or Conformance Statement Questionnaire (CSQ)." Note to all, we decided there is no shading in definitions, as the terms must standalone ] _____________________________________________________________________________ Editorial Enhancement Request Number 100 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 155) [DWC-733] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 107 Line: 3009 Section: 3.391 Problem: (tab character: character) The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for "tab character". Therefore, the phrase " character" expands to "tab character character". Action: Change " character" on P107, L3009 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 101 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 133) [DWC-711] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3023 Section: 3.394 Problem: (text file: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character." on P108, L3023 to ".". _____________________________________________________________________________ Objection Enhancement Request Number 102 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 70) [DST-15] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3097 Section: 4.407 Problem: Multiple problems: 1) Normative text in a definition. (Actually, all the trace stuff has that problem.) 2) Use of "should" (line 3095) means "it is advised that". This should be "shall except". 3) 3097 and 3099 are hard to read because they're almost the same, but different. Action: 1) Recast all these as definitions: For Trace Analyzer Process, Trace Controller Process, Trace Event, Trace Event Type, Trace Event Mapping, Trace Log, Trace Point, Trace Stream, remove all but the first sentence. Traced Process, remove all but the first two (short) sentences. 2) Move the deleted text to General Concepts (probably at 4.15) as: The Trace System allows a Traced Process to have a selection of events created for it. Traces consist of streams of Trace Event Types. A generated trace event shall be recorded in a trace stream, and optionally also in a trace log if a trace log is associated with the trace stream, except that - for a trace stream, if no resources are available for the event, the event is lost. - for a trace log, if no resources are avaialble for the event, or a flush operation does not succeed, the event is lost. Trace events may be mapped from Trace Event Types to trace event names. > Traces can be recorded into either trace streams or trace logs. For a traced process, "if"> Each Trace Point "may">. Trace Points may be filtered. . The results of the tracing operations can be analyzed and monitored by a Trace controller process or a trace analyzer process. _____________________________________________________________________________ Editorial Enhancement Request Number 103 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 158) [DWC-736] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3244 Section: 3.432 Problem: (vertical-tab character: character) The term is defined (XBD6d4, P116, L3242-3247) to be a synonym for "vertical-tab character". Therefore, the phrase " character" expands to "vertical-tab character character". Action: Change " character" on P116, L3244 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 104 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 112) [DWC-690] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3251 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P116, L3251 to "s". _____________________________________________________________________________ Comment Enhancement Request Number 105 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 156) [DWC-734] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3251-3252 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for "tab character". Therefore, the phrase " character" expands to "tab character character". Note that other changes are needed here as well! Action: Change "( and characters)," on P116, L3251-3252 to "(s and s),". _____________________________________________________________________________ Editorial Enhancement Request Number 106 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 134) [DWC-712] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3252 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " characters," on P116, L3252 to "s,". _____________________________________________________________________________ Editorial Enhancement Request Number 107 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 127) [DWC-705] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3252 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P73, L2181-2186) to be a synonym for "form-feed character". Therefore, the phrase " character" expands to "form-feed character character". Action: Change " characters," on P116, L3252 to "s,". _____________________________________________________________________________ Editorial Enhancement Request Number 108 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 124) [DWC-702] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3252 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P56, L1785-1790) to be a synonym for "carriage-return character". Therefore, the phrase " character" expands to "carriage-return character character". Action: Change " characters," on P116, L3252 to "s,". _____________________________________________________________________________ Editorial Enhancement Request Number 109 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 159) [DWC-737] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3253 Section: 3.433 Problem: (white space: character) The term is defined (XBD6d4, P116, L3242-3247) to be a synonym for "vertical-tab character". Therefore, the phrase " character" expands to "vertical-tab character character". Action: Change " characters." on P116, L3253 to "s.". _____________________________________________________________________________ Objection Enhancement Request Number 110 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 71) [DST-16] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept as marked. Change the "shall" as noted. The rest of this request is non-specific and cannot be actioned directly, although the editors have done a global shallification pass which they believe will improve the draft and make it more consistent _____________________________________________________________________________ Page: 122 Line: 3376 Section: 4.5 Problem: Shall, as in "Uppercase and Lowercase letters shall". (See .1-1996 L372.) Action: Restore shall. Actually, restore all shalls that were lost in translation. Clearly, they haven't all been. _____________________________________________________________________________ objection Enhancement Request Number 111 David.Butenhof@compaq.com Bug in XBDd4 Memory Synchronization (rdvk# 52) {drb-xbdd4-001} Tue, 5 Sep 2000 14:06:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 123 Line: 3402 Section: Memory Problem: The list of functions that "synchronize memory with respect to other threads" has not been updated from the basic 1003.1-1996 text. (This is acknowledged by the "Notes to Reviewers".) This omits functions added by XSH5, 1003.1d, and 1003.1j that exist to synchronize memory. Action: The list must be expanded, with appropriate shading and markers, to include at least the following: pthread_rwlock_rdlock, pthread_rwlock_wrlock, pthread_rwlock_tryrdlock, pthread_rwlock_trywrlock, pthread_rwlock_unlock BARRIER option: pthread_barrier_wait() SPINLOCK option: pthread_spin_lock, pthread_spin_trylock, pthread_spin_unlock TIMED option: pthread_mutex_timedlock, pthread_rwlock_timedrdlock, pthread_rwlock_timedwrlock _____________________________________________________________________________ comment Enhancement Request Number 112 Jon.Hitchcock@uniplex.co.uk Bug in XBDd4 Seconds Since the Epoch (rdvk# 46) {jjh2} Thu, 24 Aug 2000 21:27:44 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace 3495 with: The relationship between the actual time of day and the current value for Seconds Since the Epoch is unspecified. How any changes to the value of Seconds Since the Epoch are made to align to a desired relationship with the current actual time are made is implemetation-defined. As represented in Seconds Since the Epoch, each day shall be accounted for by exactly 86400 seconds. Add to rationale (repl 1463): The topic of whether Seconds Since the Epoch should account for leap seconds has been debated upon a number of occasions, and each time consensus was reached (with acknowleged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length (as measured in Seconds Since the Epoch) for all days.) Those applications which do care about leap seconds can determine how to handle them in whatever way it felt was best for that application. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. It is a practical impossiblity to mandate that a conforming implementattion must have a fixed relationship to any particular official clock (consider isloated systems, or systems performing "reruns" by setting the clock to some arbitrary time). Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. Applications must be matched to a system that provides the particular handling of external time in the way required by the application. _____________________________________________________________________________ Page: 125 Line: 3483-3495 Section: Seconds Problem: The rationale at lines 842-876 of XRATd4 (which comes from POSIX.1 1988) explains very clearly that leap seconds are deliberately ignored in the expression for seconds since the Epoch. In XBDd4, at line 3495, there has been added "Whether and how the implementation accounts for leap seconds is unspecified". This may suggest that an implementation could use a different expression which includes leap seconds. I assume that there was no intention to allow a different expression, just a desire to make some reference to leap seconds. It would be better if the definition of the concept of "Seconds Since the Epoch" explicitly said that leap seconds are not included. [However, if a change in meaning was intended, there should be some rationale for it.] Action: Change the first sentence at line 3483 to "A value that approximates the number of seconds (excluding leap seconds) that have elapsed since the Epoch." Delete line 3495 ("Whether and how the implementation accounts for leap seconds is unspecified".) _____________________________________________________________________________ objection Enhancement Request Number 113 gwinn@res.ray.com Bug in XBDd4 4.1.2 (calendar formula) (rdvk# 190) {JMG-12} Wed, 27 Sep 2000 01:56:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Also see ERN 114, 115. For the formula layout defer to editors (this is aesthetics only, the text has always had these large constants, and so should probably stay that way) _____________________________________________________________________________ Page: 125 Line: 3492-3499 Section: 4.1.2 Problem: How do we know this formula is correct? It isn't the same as original POSIX, which is probably good. It appears that the leap-century problem is solved, although this is not stated. The note (lines 3496-3499) doesn't seem to correlate with the formula. For instance, the "last term of the current expression" seems to be the 400-year rule, and yet the note claims that this term is for the 4-year cycle. This lack of correlation undermines confidence in both formula and note. Action: Verify the equation against the standard for such things, the "Explanatory Supplement to the Astronomical Almanac", P. K. Seidelmann, ed., University Science Books, 1992, ISBN 0-935702-68-7. Chapter 12 covers Calendars and conversions between them. This book is used by the navigation and astronomical communities as their official primary reference on such things. It may be good to cite the Explanatory Reference in at least the Rationale. Another useful book is "Calendrical Calculations", Nachum Dershowitz and Edward M. Reingold, Cambridge University Press, 1997. Correct the note to correspond to the formula. Instead of saying things like "the last term", repeat the intended term in quotes. For instance, one could say 'the "((tm_year+299)/400)*86400" term adds back a day every 400 years ...". Then, there is no possible ambiguity. [Annotation from CDWF: Something I *would* like to see is that the constants are recast as products, so instead of: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 it should read: tm_sec + tm_min*60 + tm_hour*60*60 + tm_yday*60*60*24 + (tm_year-70)*60*60*24*365 + ((tm_year-69)/4)*60*60*24 - ((tm_year-1)/100)*60*60*24 + ((tm_year+299)/400)*60*60*24 or even: tm_sec + tm_min*60 + tm_hour*60*60 + 60*60*24* ( tm_yday + (tm_year-70)*365 + (tm_year-69)/4 - (tm_year-1)/100 + (tm_year+299)/400 ) ] _____________________________________________________________________________ Objection Enhancement Request Number 114 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 167) [DWC-759] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 125 Line: 3494 Section: 4.12 Problem: (seconds since the epoch) In my objection DWC-XBD-24 on XBD6 draft 1, I requested that the last line of the expression on P125, L3492-3494 (in this draft) be added. Somewhere along the line a closing parenthesis was lost. Action: Change "((tm_year-1/100)*86400" on P125, L3494 to "((tm_year-1)/100)*86400". ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 115 Jon.Hitchcock@uniplex.co.uk Bug in XBDd4 Seconds Since the Epoch (rdvk# 45) {jjh3} Thu, 24 Aug 2000 21:27:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 125 Line: 3496-3499 Section: Seconds Problem: The note about the leap year adjustment refers to the original expression (that was in earlier versions of the standard) and also to the change that has been made. This makes no sense to a new reader. Action: Change lines 3496-3499 to: Note: The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. _____________________________________________________________________________ Objection Enhancement Request Number 116 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 91) [DST-110] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The wording/requirement is from ISO C , and no change is currently perceived as being needed (XSHd4 page number is 136 line no is 3820). _____________________________________________________________________________ Page: 128 Line: 3699 Section: 6 Problem: See D3 ERN 83. The draft *requires* that characters be representable in a byte. Unicode *requires* that its characters are represented in TWO bytes. These are not compatible, thus apparently precluding the possibility of a pure Unicode implementation. (Yeah, we can argue about flexible definitions of "byte", but I doubt that anyone will buy into char* being a pointer to a 16-bit entity.) Action: I don't know what to do, but I doubt the intent is to preclude that. (Although I do understand the desire to avoid multibyte in the base character set.) Does "The encoded values associated with the members of the portable character set are each represented using the smallest storage space required for any character in that character set." work? _____________________________________________________________________________ Objection Enhancement Request Number 117 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 92) [DST-111] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This requirement is in C99 (See 6.2.5, para 3). No change is required since the requirement is from a base document (C99) and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 128 Line: 3701 Section: 6 Problem: Still unresolved: why do characters have to be positive? See ERN-84, and 93 from the time before that. (A respnse of "see ERN 83", which doesn't address the issue at all, doesn't apply.) Action: Why? (Note that this isn't in the -1990/-1996 POSIX.) _____________________________________________________________________________ Editorial Enhancement Request Number 118 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 113) [DWC-691] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 3566 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters." on P129, L3566 to "s.". _____________________________________________________________________________ Editorial Enhancement Request Number 119 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 144) [DWC-722] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 3567 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P129, L3567 to ".". _____________________________________________________________________________ Editorial Enhancement Request Number 120 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 145) [DWC-723] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 130 Line: 3606 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P130, L3606 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 121 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 146) [DWC-724] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 130 Line: 3607 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P130, L3607 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 122 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 147) [DWC-725] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 130 Line: 3608 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P130, L3608 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 123 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 114) [DWC-692] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 131 Line: 3635-3636 Section: 5 Problem: (file format notation: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters;" on P131, L3635-3636 to "s;". _____________________________________________________________________________ Comment Enhancement Request Number 124 Keld Simonsen bug in XBDd4 (rdvk# 249) [KS-6] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add p 135, line 3811 "Characters defined in Table 6-2 on p xx may also be used in character set description files." _____________________________________________________________________________ Page: 135 Line: 3805 Section: 6.1 Problem: POSIX-2 uses some names for control characters in addition to the ones in Table 6.1, namely table 6.2 Action: Add a reference to Table 6.2 here. _____________________________________________________________________________ Objection Enhancement Request Number 125 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 90) [DST-109] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the text is just the first paragraph If the encoded values associated with each member of the portable character set are not invariant across all locales supported by the implementation, if an application accesses any pair of locales where the character encodings differ, or accesses data from an application running in a locale which has different encodings from the application's current locale, the results are unspecified. _____________________________________________________________________________ Page: 135 Line: 3814 Section: 6 Problem: See D3 ERN 28. This wording is still wrong. Try this scenario: I have an implementation that has exactly one locale that's ASCII based installed on it. All is well. Now I install a second locale, this time using EBCDIC (not the same base character set). I now have the situation of "the encoded values associated with each member of the PCS are not invariant". If I now run in the ASCII based locale (having NEVER run anything in the EBCDIC based locale) I have accessed one of those locales, and thus accessed "those locales", and the results become unspecified. The wording is overbroad. I don't disagree with the intent, but if the very act of installing an unused locale can make EVERYTHING unspecified, which is what a strict reading of the words here says, it's overbroad. Action: Use: If the encoded values associated with each member of the portable character set are not invariant across all locales supported by the implementation, if an application accesses any pair of locales where the character encodings differ, or accesses data from an application running in a locale which has different encodings from the application's current locale, the results are unspecified. The objective here is to say that the mere presence of the locales is not enough to trigger the unspecified state. Rather actually using more than one (or data from more than one) will do it. _____________________________________________________________________________ Objection Enhancement Request Number 126 Keld Simonsen bug in XBDd4 (rdvk# 250) [KS-7] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_127 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 135 Line: 3819 Section: 6.1 Problem: The ISO C standard has removed the requirement for a NUL character to be all zeroes. Action: Remove this requirement in line 3819 and other places. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 127 Clive D.W. Feather bug in XBDd4 (rdvk# 242) [CDWF-107] Thu, 28 Sep 2000 11:26:49 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is in ISO C and the only addition we are making is naming the null character NUL. This is allowable. _____________________________________________________________________________ Page: 136 Line: 3819 Section: 6.1 Problem: The ISO C standard does not have a concept of "all bits zero" in an abstract value, only in representations of integer types. Line 3822 already has the correct requirement, which is that it is zero if placed in a char object. Action: Change line 3819 to read: A null character, NUL, shall be in the set of characters. or: A null character, NUL, shall be in the set of characters. This value is used in the C language to indicate "end of string". _____________________________________________________________________________ Objection Enhancement Request Number 128 Clive D.W. Feather bug in XBDd4 (rdvk# 243) [CDWF-108] Thu, 28 Sep 2000 11:26:49 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: this is our definition, not inherited from C. Therefore the extension above and beyond C's requirements does not need to be called out. _____________________________________________________________________________ Page: 136 Line: 3821-3822 Section: 6.1 Problem: The requirement that values must be positive only applies to the *C* portable character set; the characters dollar, at, and grave are not part of the set. Action: Either: * lines 3702, 3735, and 3772 should be CX shaded or append to line 3822 (CX shaded): This requirement is not part of C99 for the characters dollar, at, and grave. _____________________________________________________________________________ Objection Enhancement Request Number 129 Keld Simonsen bug in XBDd4 (rdvk# 251) [KS-8] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 136 Line: 3827 Section: 6.1 Problem: The text can be read as allowing other characters than the ones specified in the POSIX locale. This is not intended. The POSIX and C locales are only defined as the specified normative POSIX locale defines. Action: Remove "Implementations may also add other characters. " ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 130 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 93) [DST-112] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: take the change in the action below but add "except as noted below" to end of first sentence. _____________________________________________________________________________ Page: 137 Line: 3884 Section: 6 Problem: 1) Requiring the implementor to use judgement as to what the set of symbols with identical glyphs is is vague at best. 2) Tables that are numbered should be referred to by number. 3) It's not made completely clear that ALL the alternative coding of the duplicate characters must be included. Action: Use: Each symbolic name specified in Table 6-1 on page 135 shall be included in the file and shall be mapped to a unique coding value. The glyphs {, }, _, -, /, \, ., ^, [Ed- use CW font for these] have more than one symbolic name; all symbolic names for each such glyph shall be included, each with identical encoding. If some or all of the control characters identified in table 6-2 are supported by the implementation, the symbolic names and their corresponding encoding values shall be included in the file. Some of the encodings associated with the symbolic names in table 6-2 may be the same as characters found in table 6-1; both names shall be provided for each encoding. _____________________________________________________________________________ Editorial Enhancement Request Number 131 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 115) [DWC-693] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 3900 Section: 6.4 Problem: (character set description file: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters," on P138, L3900 to "s,". _____________________________________________________________________________ Editorial Enhancement Request Number 132 Keld Simonsen bug in XBDd4 (rdvk# 248) [KS-5] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 3686 Section: 6.1 Problem: 10646 was issued in a 2nd edition in 2000 Action: change 10646-1:1993 to 10646-1:2000 (and note that there be no space around the colon). Also change other places for IS 10646. [Ed recommendation: Accept as marked as above, but we have a style for names of standards and insert a space] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 133 Keld Simonsen bug in XBDd4 (rdvk# 246) [KS-3] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: An interp has also been filed to determine if these lines should be removed, add a revnote PASC Interp 1003.2 #196 has been filed to determine if these lines related to charmaps should be deleted. _____________________________________________________________________________ Page: 139 Line: 3979-3981 Section: 6.4 Problem: The concept of charmaps using IS 10646 position values is not clearly described, and handled better with Repertoiremaps as proposed in KS-2. Action: Remove line 3979-3981. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 134 Keld Simonsen bug in XBDd4 (rdvk# 247) [KS-4] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team believes that accepting the proposed change would decrease consensus. _____________________________________________________________________________ Page: 139 Line: 3995-4017 Section: 6.4 Problem: WIDTH, WIDTH_VARIABLE, WIDTH_DEFAULT statements should be located in the locale definition, as they are related to abstract (wide) characters. Abstract characters are defined in IS 10646, and a number of attributes to the abstract characters are also defined here, including WIDTH attributes. Thus for an abstract character, with double width, this has the width 2 regardless of the encoding, be it in IS 10646 or a national double-byte encoding. The LC_CTYPE category should be practically identical for all locales so there is no overhead in doing this once and for all in a standard locale, that then others can refer to. As the WIDTH attribute is an attribute of an abstract character and not related to encoding, it is a big architectural mistake to move it into the encoding specification of the charmap, and destroying the principle of making locales contain all encoding independent information. Action: Remove 3999-4017 and provide for equivalent functionality in locale LC_CTYPE. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 135 Keld Simonsen bug in XBDd4 (rdvk# 245) [KS-2] Thu, 28 Sep 2000 02:13:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because there is not acceptance that this is the right way to solve the perceived problem given implementation experience. The review team also believes that accepting the proposed change would decrease consensus. _____________________________________________________________________________ Page: 141 Line: 4035 Section: 6.4 Problem: A repertoiremap description file format, that describes which repertoire is covered and how symbolic character names relate to IS 10646, is missing. This file describes the concept of character repertoire of SC2 and lists abstract characters, (not encoded characters as in charmaps). This concept is used in the cultural registry of ISO/IEC 15897 and in PDTR 14652 and also (without the specific name of repertoire map) in The Open Group locale registry. As .2b issues has not been introduced before D4 it should be allowed to comment on .2b issues with this comment round. Action: Introduce a new subclause 6.5 with the following text: 6.5 Repertoiremap Locale and Charmap sources may be specified in a coded character set independent way, using symbolic character names. The relation between the symbolic character names and characters may be specified via a Repertoiremap, which defines the repertoire of characters defined for a Locale, and the symbolic character names and corresponding abstract character (by a reference to ISO/IEC 10646). The repertoire mapping is defined by specifying the symbolic character name and the ISO/IEC 10646 code position in hexadecimal form (with a preceding 'U') and optionally the long ISO/IEC 10646 character name in the following syntax: "%s %s %s\n",,<10646-short-identifier>, The symbolic character name and the ISO/IEC 10646 short identifier are each surrounded by angle brackets <>, and the fields shall be separated by one or more spaces or tabs on a line. If a right angle bracket or an escape character is used within a symbolic name, it shall be preceded by the escape character. Characters not in ISO/IEC 10646 may be referenced by the symbolic character names ... The escape character can be redefined from the default reverse solidus (\) with the first line of the Repertoiremap containing the string "escape_char" followed by one or more spaces or tabs and then the escape character. Several symbolic character names can refer to the same abstract character, and are then used as synonyms in locales and charmaps. The set of .. and .. symbolic names (no lowercase letters) are predefined and refers to the corresponding code points of ISO/IEC 10646 with the same short identifier. ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 136 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 116) [DWC-694] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4112 Section: 7.3 Problem: (locale definition: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P145, L4112 to "s". _____________________________________________________________________________ Editorial Enhancement Request Number 137 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 117) [DWC-695] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4119 Section: 7.3 Problem: (locale definition: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters." on P145, L4119 to "s.". _____________________________________________________________________________ Editorial Enhancement Request Number 138 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 118) [DWC-696] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4123 Section: 7.3 Problem: (locale definition: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P145, L4123 to "s". _____________________________________________________________________________ Objection Enhancement Request Number 139 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 97) [DST-116] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 148 Line: 4251 Section: 7.3.1 Problem: This paragraph is rationale, and is duplicted at 1730 in XRAT. Action: Delete. _____________________________________________________________________________ Editorial Enhancement Request Number 140 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 148) [DWC-726] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4272 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P149, L4272 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 141 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 149) [DWC-727] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4275 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P149, L4275 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 142 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 150) [DWC-728] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4277 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P149, L4277 to ".". _____________________________________________________________________________ Objection Enhancement Request Number 143 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 94) [DST-113] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We will rework this complete section and change the "cans" to shall's as per .2 p147-150 _____________________________________________________________________________ Page: 149 Line: 4282 Section: 7.3.1 Problem: (See D3 ERN 104) "Can" specfies what it is possible for an applicaiton to do. An application can specify a control character here, but it would be wrong. The standard is making a requirement on the application (enforced by the implementation, probably). Action: Change to "Characters specified for the keyword cntrl shall not be specified." _____________________________________________________________________________ Editorial Enhancement Request Number 144 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 151) [DWC-729] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4284 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P149, L4284 to ".". _____________________________________________________________________________ Editorial Enhancement Request Number 145 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 152) [DWC-730] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4288 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P149, L4288 to "". _____________________________________________________________________________ comment Enhancement Request Number 146 Sandra O'donnell BUG in XBDd4 (rdvk# 252) {compaq-smo-003} Thu, 28 Sep 2000 15:57:09 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4302-4303 Section: Locale Problem: Ulrich Drepper writes in objection {ud-7}: The definition of the xdigit character class in XBD defines on top of the POSIX specification: The definition of character class xdigit requires that the characters included in charater class digit be included here also. In my opinion this is wrong and since this is missing in the POSIX specs probably not intended in the original design. The digit class can and probably should contain all the decimal digit forms from all the different alphabets. Requiring all these forms also in xdigit makes the whole class asymmetric since one cannot reasonably also add all the different forms of the letters a to f from all the alphabets (including Greek, Cyrillic, ...). . . The description of the digit class states (lines 4247-4254): "In a locale definition file, only the digits , , , , , , , , , and can be specified...The definition of character class digit requires that only ten characters -- the ones defining digits -- can be specified; alternative digits (for example, Hindi or Kanji) cannot be specified here. However, the encoding may vary if an implementation supports more than one encoding." Thus, the digit class can *not* "contain all the decimal digit forms from all the different alphabets." Action: Ulrich recommended removing the paragraph in lines 4302 to 4303 of xdigit because he was concerned the digit class might contain many different sets of digits. I believe that is not possible, so I recommend that the existing wording stay. _____________________________________________________________________________ objection Enhancement Request Number 147 drepper@redhat.com Bug in XBDd4 Locale (rdvk# 160) {ud-7} Tue, 26 Sep 2000 06:08:56 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Withdrawn by the originator _____________________________________________________________________________ Page: 149 Line: 4302-4303 Section: Locale Problem: The definition of the xdigit character class in XBD defines on top of the POSIX specification: The definition of character class xdigit requires that the characters included in charater class digit be included here also. In my opinion this is wrong and since this is missing in the POSIX specs probably not intended in the original design. The digit class can and probably should contain all the decimal digit forms from all the different alphabets. Requiring all these forms also in xdigit makes the whole class asymmetric since one cannot reasonably also add all the different forms of the letters a to f from all the alphabets (including Greek, Cyrillic, ...). Also, xdigit is something completely artificial, it is only used to represent numbers for computer use. There is no real-life use. Action: Remove the paragraph in lines 4302 to 4303. Allow the xdigit class to contain only ASCII 0 to 9, a to f, and A to F even if the digit class contains a lot of different sets of digits. _____________________________________________________________________________ Editorial Enhancement Request Number 148 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 119) [DWC-697] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4304 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters." on P149, L4304 to "s.". _____________________________________________________________________________ Editorial Enhancement Request Number 149 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 157) [DWC-735] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4305 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for "tab character". Therefore, the phrase " character" expands to "tab character character". Action: Change " and characters" on P149, L4305 to "s and s". _____________________________________________________________________________ Objection Enhancement Request Number 150 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 95) [DST-114] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 150 Line: 4313 Section: 7.3.1 Problem: As above, the application is prohibited from doing something, which is "shall not". Action: cannot -> shall not. _____________________________________________________________________________ Objection Enhancement Request Number 151 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 96) [DST-115] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The editors passed this to ISO who responded: The use of "cannot" is perfectly acceptable... it is in fact given in the ISO Directives Part 3 as one of the admissible verbal forms (see annex E, table E.4). _____________________________________________________________________________ Page: 150 Line: 4313 Section: 7.3.1 Problem: "cannot" (the runtogether word) isn't appropriate in the standard because it's not clearly the magic word "can". Action: Globally change all instances of "cannot" to "can not" (mechanically). [Ed recommendation: NONE This was discussed last time and we decided to leave the text as is. I have even seen "cannot" in .1] _____________________________________________________________________________ Editorial Enhancement Request Number 152 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 153) [DWC-731] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 151 Line: 4372 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character," on P151, L4372 to ",". _____________________________________________________________________________ Editorial Enhancement Request Number 153 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 154) [DWC-732] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 151 Line: 4381 Section: 7.3.1 Problem: (LC_CTYPE: character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character" on P151, L4381 to "". _____________________________________________________________________________ Comment Enhancement Request Number 154 Keld Simonsen BUG in XCUd4 (rdvk# 214) [KS-10] Thu, 28 Sep 2000 03:07:12 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_83 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 156 Line: 4565 Section: 7.3.2 Problem: The sentence "The LC_COLLATE category provides a collation sequence definition..." and the following text blurs the distinction between collating SEQUENCE and collating ORDER. We've taken care of some of that with the work in AI2000-05-010, and very informative side discussions have allieviated some more of the confusion. (Copeland) There need not be this confusion, as probably only the collation order is needed for REs Action: Specify RE ranges like [a-c] to be based on the collation ordering, and if both points are either in class lower or upper, then include only characters that are lowercase or uppercase, respectively. _____________________________________________________________________________ comment Enhancement Request Number 155 Jon.Hitchcock@uniplex.co.uk Bug in XBDd4 LC_TIME (rdvk# 162) {jjh11} Mon, 25 Sep 2000 19:49:58 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Reword introuction to 7.3.5.2 to show that the entire section is XSI. Move all examples in chapter 7 to XRAT so chap 7 more aligned with original .2. Change 5266 table header last col to "Conversion Specifier/Modifier" The complete chapter 7 has been reworked with assistance from the commenter. This text has been recirculated to the group between D4 and D5. _____________________________________________________________________________ Page: 170-174 Line: 5215-5391 Section: LC_TIME Problem: The XSI shading is confusing, and may even be wrong. If you ignore the XSI-shaded text, then: a) lines 5218-5264 have no introduction to say what the constants can be used for, b) line 5369 is a heading for a table with no entries, c) the POSIX locale values for LC_TIME are only defined as localedef text. For other categories, the POSIX locale values are defined twice: once as localedef text, and again as a human-readable table. Action: Warning: I am indeed confused by this shading, and do not really know what is meant, so these suggestions need to be checked. XSI-shade the whole of lines 5215-5264. Remove lines 5265-5285. Change lines 5315-5316 to say: The LC_TIME category definition of the POSIX locale follows; the code listing depicts the localedef input; the table represents the same information with the addition of conversion specifiers used by the date utility and the strftime(), wcsftime(), and strptime() functions and nl_langinfo() constants. Arrange the table at lines 5369-5391 to be like those for other categories by adding columns labelled "localedef Keyword" and "Conversion specifier" using the information removed from lines 5269-5284. Remove shading from lines 5370-5391, and add the note: In the preceding table, the langinfo Constant column represents an XSI-conformant extension. _____________________________________________________________________________ Comment Enhancement Request Number 156 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 73) [DST-18] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Use: at line 5908-5910, append to end of sentence "and shall not begin with a digit." After 5915, add note: "Other applications may also have difficulty dealing with environment variable names that start with a digit. For this reason use of such names is not recommended anywhere." After 1883 in XRAT add: "In addition to the obvious conflict with the shell syntax for positional parameter substitution, some historical applications including some shells exclude names with leading digits from the environment." _____________________________________________________________________________ Page: 187 Line: 5908 Section: 8.1 Problem: Although correct, this can be misleading because of the fact that environment variables are most visible through the shell, and environment variables which are numbers do very strange things in the shell environment (because they become parameter numbers). (The purpose of the change is to avoid a later interp request and/or validation problem caused by taking the lack of requirement that env variables begin with a non-digit either too literally or as an error in the standard. E.g. ksh does not recognize 9xy=abc as an assignment, and apparently simply ignores set 9xy=abc . If you use putenv() to set 9xy=abc in the environment, you can retrieve it with getenv(), but system("env | grep 9xy") yields nothing. This is consistent across several systems including Solaris and Linux.) Action: Add at 5915: Note that the shell treats variables which start with a digit as parameter numbers or otherwise specially, and thus using environment variables which begin with a digit may have unexpected consequences. _____________________________________________________________________________ Objection Enhancement Request Number 157 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 163) [DWC-756] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges." _____________________________________________________________________________ Page: 190 Line: 6034-6036 Section: 8.2 Problem: (internationalization variables: NLSPATH) Recent postings on various security aliases have identified a security hole that can be exploited by replacing system message catalogs with user supplied message catalogs using NLSPATH when invoking a setuid utility. This issue is being discussed by a group of security experts at The Open Group (since this text came from SUSv2). When they complete their discussions, I expect they will forward a resolution to The Open Group's Base Working group to fix SUSv2. This is being submitted here now to be sure that an objection is on the books for the revision. If the security experts addressing this issue alter this proposal, I will submit the replacement fix at the draft 4 ballot resolution meeting in Austin. There are related fixes in other parts of my ballot to address changes needed to catopen() and catgets() in XSH6d4. Action: Change: Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Doing so causes undefined behavior in the standard utilities. on P190, L6034-6036 to: Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Setting NLSPATH to override the default system path shall cause undefined results in the standard utilities and in applications with appropriate privileges. ------------------------------------------------------------------------------ __________________________________________________________________________________ comment Enhancement Request Number 158 Jon.Hitchcock@uniplex.co.ukBug in XBDd4 Internationalization Variables (rdvk# 89) {jjh6} Fri, 22 Sep 2000 19:49:56 +0100 (BST) __________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The review team disagrees with the problem statement because they cannot make this requirement work;the locale categories are not independent. Note that there are other changes as a result of related ERNs that will result in clarifying text to the draft. __________________________________________________________________________________ Page: 191 Line: 6078 Section: Internationalization Problem: Line 6078 says that if a locale value is not recognised by the implementation, the behaviour is unspecified. There is no specification of the effect on other locale categories if one of the LC_* variables has an invalid setting. This is contradicted in the other documents. For more explanation see austin-group message 1280, which was not disagreed with. Action: After line 6078 add: But the precedence rules are applied independently for each category, and the locale for one category cannot be changed by setting the variable for another category. _____________________________________________________________________________ objection Enhancement Request Number 159 ajosey@opengroup.org Bug in XBDd4 8.3 (rdvk# 47) {tog.aug31.6} Thu, 31 Aug 2000 09:28:59 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 192 Line: 6122 Section: 8.3 Problem: wording change caused loss of strict conformance requirement for applications. Action: change "a portable application" -> "a strictly conforming application" _____________________________________________________________________________ Editorial Enhancement Request Number 160 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 135) [DWC-713] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6282 Section: 9.2 Problem: (regular expression general requirements: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character." on P197, L6282 to ".". _____________________________________________________________________________ Editorial Enhancement Request Number 161 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 136) [DWC-714] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6283 Section: 9.2 Problem: (regular expression general requirements: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P197, L6283 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 162 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 137) [DWC-715] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6286-6287 Section: 9.2 Problem: (regular expression general requirements: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " characters; if not stated otherwise, the use of literal characters" on P197, L6286-6287 to "s; if not stated otherwise, the use of literal s". _____________________________________________________________________________ Editorial Enhancement Request Number 163 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 138) [DWC-716] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6288-6289 Section: 9.2 Problem: (regular expression general requirements: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " characters to match are responsible for eliminating any character" on P197, L6288-6289 to "s to match are responsible for eliminating any ". _____________________________________________________________________________ Editorial Enhancement Request Number 164 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 139) [DWC-717] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6289 Section: 9.2 Problem: (regular expression general requirements: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P197, L6289 to "". _____________________________________________________________________________ objection Enhancement Request Number 165 eggert@twinsun.com Bug in XBDd4 9.3.5 (rdvk# 51) {eggert-2000083101} Fri, 1 Sep 2000 00:26:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The problem has been accepted as follows The following changes should be made. The notation [+ +] surrounds additions from d4, and [- -] surrounds deletions. p.58 s.3 Definitions 1848 [-3.103 Collating Element Order 1849 The relative order of collating elements as determined by the setting of the LC_COLLATE 1850 category in the current locale. 1851 The collating element order is used in range expressions in REs and is determined by the order in 1852 which collating elements are specified between order_start and order_end keywords in the 1853 LC_COLLATE category.-] p.59 1858 3.105 Collation Sequence 1859 The relative order of collating elements as determined by the setting of the LC_COLLATE 1860 category in the current locale. The collation sequence is used for sorting and is determined from 1861 the collating weights assigned to each collating element. In the absence of weights, the collation 1862 sequence is [-also the collating element order.-] [+the order in which collating elements are specified between order_start and order_end keywords in the LC_COLLATE category.+] p.158 s.7.3.2.3 The order_start Keyword 4662 The character[- (and collating element)-] order is defined by the order in which characters and 4663 elements are specified between the order_start and order_end keywords. [-This character order is 4664 used in range expressions in regular expressions (see Chapter 9).-] Weights assigned to the p.159 s.7.3.2.4 Collation Order 4746 The collation order as defined in this section [-defines-][+affects+] the interpretation of bracket expressions in 4747 regular expressions (see Section 9.3.5 (on page 199)). p.160 4766 1. The UNDEFINED means that all characters not specified in this definition (explicitly or 4767 via the ellipsis) shall be ignored for collation purposes[-; for regular expression purposes 4768 they are ordered first-]. p.195 s.9.2 Regular Expression General Requirements 6300 character, but also its case counterpart (if any), shall be matched. This definition of case- 6301 insensitive processing is intended to allow matching of multi-character collating elements as 6302 well as characters[-. For example-], as each character in the string is matched using both its cases[+. For example, in a locale where "Ch" is a multi-character collating element and where a matching list expression matches such elements+], 6303 the RE "[[.Ch.]]" when matched against the string "char", is in reality matched against 6304 "ch", "Ch", "cH", and "CH". p.199 s. 9.3.5 RE Bracket Expression 6347 classes, character classes, or range expressions. [-Portable applications shall not use range 6348 expressions, even though all implementations shall support them. -]The right-bracket (']') 6360 2. A matching list expression specifies a list that shall match any [+character in any+][-one-] of the expressions 6361 represented in the list. The first character in the list shall not be the circumflex; for 6362 example, "[abc]" is an RE that matches any of the characters 'a', 'b', or 'c'. [+It is unspecified whether a matching list expression matches a multi-character collating element that is matched by one of the expressions.+] 6363 3. A non-matching list expression begins with a circumflex ('^'), and specifies a list that shall 6364 match any character [-or collating element -]except for the expressions represented in the list 6365 after the leading circumflex. For example, "[^abc]" is an RE that matches any character 6366 [-or collating element -]except the characters 'a', 'b', or 'c'. [+It is unspecified whether a non-matching list expression matches a multi-character collating element that is not matched by any of the expressions.+] The circumflex shall have this 6372 that make up the multi-character collating element. For example, if the string "ch" is a 6373 collating element in the current collation sequence with the associated collating symbol 6374 , the expression "[[.ch.]]" shall be treated as an RE [+containing the collating symbol+][-matching the character 6375 sequence-] 'ch', while "[ch]" shall be treated as an RE matching 'c' or 'h'. Collating 6376 symbols are recognized only inside bracket expressions.[- This implies that the RE 6377 "[[.ch.]]*c" shall match the first to fifth character in the string "chchch".-] If the string 6378 is not a collating element in the current [-collating sequence definition, or if the collating 6379 element has no characters associated with it (for example, see the symbol in the 6380 example collation definition shown in Section 7.3.2.2 (on page 157)), the symbol shall be 6381 treated as an invalid expression-][+locale, the expression is invalid+]. p.200 6402 7. [+In the POSIX locale, a+][-A-] range expression represents the set of collating elements that fall between two elements 6403 in the [+collation sequence+][-collating element order of the current locale-], inclusive.[+ In other locales, a range expression has unspecified behavior: strictly conforming applications shall not rely on whether the range expression is valid, or on the set of collating elements matched.+] A range expression shall be 6404 expressed as the starting point and the ending point separated by a hyphen ('-'). 6405 [-Range expressions shall not be used in portable applications because their behavior is 6406 dependent on the collating sequence.-] 6407 In the following, all examples assume[- the collation sequence specified for-] the POSIX locale[-, 6408 unless another collation sequence is specifically defined-]. 6412 within a bracket expression, but only outside the range.[- For example, the unspecified 6413 expression "[[=e=]-f]" should be given as "[[=e=]e-f]". The ending range point 6414 shall collate equal to or higher than the starting range point; otherwise, the expression is 6415 treated as invalid. The order used is the order in which the collating elements are specified 6416 in the current collation definition. One-to-many mappings (see the description of 6417 LC_COLLATE in Section 7.3.2 (on page 155)) are not performed. For example, assuming 6418 that the character eszet ('_') is placed in the collation sequence after 'r' and 's', but 6419 before 't' and that it maps to the sequence "ss" for collation purposes, then the 6420 expression "[r-s]" matches only 'r' and 's', but the expression "[s-t]" matches 6421 's', '_', or 't'.-] [+If the represented set of collating elements is empty, it is unspecified whether the expression matches nothing, or is treated as invalid.+] 6430 '@' inclusive; and the expression "[a--@]" is[+ either+] invalid[+ or equivalent to "@"+], because the letter 'a' follows the 6431 symbol '-' in the POSIX locale. To use a hyphen as the starting range point, it shall either XCUd4 changes: p.3137 tr Utility // This change is independent of the other changes in this proposal. // It allows the implementation to define tr ranges to have the same // meaning as range expressions, and it clarifies some ambiguous // wording about collation sequence versus collating element order. 35710 c-c [+In the POSIX locale, represents+][-Represents-] the range of collating elements between the range endpoints (as long as 35711 neither endpoint is an octal sequence of the form \octal), inclusive, as defined by 35712 the [+collation sequence.+][-current setting of the LC_COLLATE locale category. The application shall 35713 ensure that the starting endpoint precedes the second endpoint in the current 35714 collation order.-] The characters or collating elements in the range shall be placed in 35715 the array in ascending collation sequence. [+If the the the second endpoint precedes the starting endpoint in the collation sequence, it is unspecified whether the range of collating elements is empty, or this construct is treated as invalid. In locales other than the POSIX locale, this construct has unspecified behavior.+] XRATd4 changes: p.3357 s.A.7.3.2 // Remove text that merely repeats XBDd4 p.156 s.7.3.2.3 lines // 4662-4666, which is changed above. 1812 [-The character (and collating element) order is defined by the order in which characters and 1813 elements are specified between the order_start and order_end keywords. This character order is 1814 used in range expressions in regular expressions (see the Base Definitions volume of IEEE Std. 1003.1-200x, 1815 Chapter 9, Regular Expressions). Weights assigned to the characters and elements define the 1816 collation sequence; in the absence of weights, the character order is also the collation sequence.-] p.3362 s.A.9.1 2016 bracket expression only matched a single character. [-If, however, the bracket expression defines, 2017 for example, a range that includes ij, then this particular bracket expression also matches a 2018 sequence of the two characters 'i' and 'j' in the string.-] [+POSIX.2-1992 required bracket expressions like [^[:lower:]] to match multi-character collating elements such as "ij". However, this requirement led to behavior that many users did not expect and that could not feasibly be mimicked in user code, and it was rarely if ever implemented correctly. The current standard leaves it unspecified whether a bracket expression matches a multi-character collating element, allowing both historical and POSIX.2-1992 implementations to conform.+] p.3363 s.A.9.2 // Remove text that merely repeats XBDd4 p.195 s.9.2 lines 6300-6304, // which is changed above. 2036 [-The definition of case-insensitive processing is intended to allow matching of multi-character 2037 collating elements as well as characters. For instance, as each character in the string is matched 2038 using both its cases, the RE "[[.Ch.]]", when matched against "char", is in reality matched 2039 against "ch", "Ch", "cH", and "CH".-] p.3364 s.A.9.3.5 RE Bracket Expressions 2073 Range expressions are, historically, an integral part of REs. However, the requirements of 2074 ``natural language behavior'' and portability do conflict[-:-][+. In the POSIX locale,+] ranges must be treated according to the 2075 [-current -]collating sequence and include such characters that fall within the range based on that 2076 collating sequence, regardless of character values. [-This means, however, that the interpretation 2077 will differ depending on collating sequence. If, for instance, one collating sequence defines 'a as 2078 a variant of 'a', while another defines it as a letter following 'z', then the expression "[a-z]" 2079 is valid in the first language and invalid in the second. This kind of ambiguity should be avoided 2080 in portable applications, and therefore the standard developers elected to state that ranges must 2081 not be used in strictly conforming applications; however, implementations must support them.-] [+In other locales, ranges have unspecified behavior.+] 2093 As noted previously, the new syntax and rules have been added to accommodate other 2094 languages than English. The remainder of this section describes the rationale for these 2095 modifications. [+In the POSIX locale, a regular expression that starts with a range expression matches a set of strings that are contiguously sorted, but this is not necessarily true in other locales. For example, a French locale might have the following behavior: $ ls alpha Alpha estimi ESTIMI iti eurjka $ ls [a-e]* alpha Alpha estimi eurjka Such disagreements between matching and contiguous sorting are unavoidable because POSIX sorting cannot be implemented by a deterministic finite-state automaton. Historical implementations used native character order to interpret range expressions. POSIX.2-1992 instead required collating element order (CEO): the order that collating elements were specified between the order_start and order_end keywords in the LC_COLLATE category of the current locale. CEO had some advantages in portability over the native character order, but it also had some disadvantages: * CEO could not feasibly be mimicked in user code, leading to inconsistencies between POSIX matchers and matchers in popular user programs like Emacs, ksh and Perl. * CEO caused range expressions to match accented and capitalized letters contrary to many users' expectations. For example, [a-e] typically matched both "E" and "a" but neither "A" nor "i". * CEO was not consistent across implementations. In practice CEO was often less portable than native character order. For example, it was common for the CEOs of two implementation-supplied locales to disagree, even if both locales were named "da_DK". Because of these problems, some implementations of regular expressions continued to use native character order. Others used the collation sequence, which is more consistent with sorting than either CEO or native order, but which departs further from the traditional POSIX semantics because it generally requires [a-e] to match either "A" or "E" but not both. As a result of this kind of implementation variation, programmers who wanted to write portable regular expressions could not rely on POSIX.2-1992's guarantees in practice. While revising the standard, lengthy consideration was given to proposals to attack this problem by adding an API for querying the CEO to allow user-mode matchers, but none of these proposals had implementation experience and none achieved consensus. Leaving the standard alone was also considered, but rejected due to the problems described above. The current standard leaves unspecified the behavior of a range expression outside the POSIX locale. This makes it clearer that portable applications should avoid range expressions outside the POSIX locale, and it allows implementations and compatible user-mode matchers to interpret range expressions using native order, CEO, collation sequence, or other, more advanced techniques. POSIX.2-1992 required [b-a] to be an invalid expression in the POSIX locale, but this requirement has been relaxed in this version of the standard so that [b-a] can instead be treated as a valid expression that does not match any string.+] _____________________________________________________________________________ Page: 199 Line: 6347 Section: 9.3.5 Problem: There is no portable way in POSIX to discern the collating element order, and hence no portable way to write conforming matchers for range expressions and nonmatching list expressions. Ulrich Drepper was given the job of proposing an API to attack this problem (AI 2000-05-010; see ). An extensive discussion on the austin-group@opengroup.org mailing list ensued, but none of the proposed APIs come close to solving the problem entirely, and there is no implementation experience for any of them. Action: The proposed solution attacks the problem by relaxing and simplifying the POSIX requirements for matching. As it happens, many modern implementations (including GNU/Linux and Solaris 8) already violate the POSIX requirements anyway, so relaxing the POSIX requirements reflects widespread implementation practice. Since the proposed change relaxes the requirements on implementations, all implementations that conform to POSIX.2-1992 also conform to the proposed change. The proposed change solves the original problem indirectly, because it means that applications like Korn's ksh and GNU grep can easily satisfy the revised standard by using any of several portable methods (e.g. strcoll, strcmp) to match range expressions and nonmatching list expressions. As a side effect, the proposed change removes some wording that has been edited inaccurately away from the POSIX.2-1992 text. For example, draft 4 says "portable applications shall not use range expressions", which is apparently equivalent to saying "applications shall not use range expressions" as the term "portable applications" is nowhere defined. Finally, the proposed change allows implementations freedom to support user expectations better than POSIX.2-1992 does. For example: * POSIX.2-1992 forbids "[a-e]" from consistently matching both accented "a" and accented "e" as most users expect, but the proposed change allows it. * POSIX.2-1992 forbids "tr" ranges from having semantics identical to range expressions in all locales, but the proposed change allows it. * In some locales POSIX.2-1992 requires "^[^[:lower:]]+$" to match a line containing only lowercase letters, but the proposed change allows it to not match in all locales. * In some locales POSIX.2-1992 requires "^[^c]" to match lines starting with "c", but the proposed change allows it to not match in all locales. Here are the proposed changes. Sorry about the long lines, but they're taken from the original draft 4 text: ---- Remove: 6347 Portable applications shall not use range 6348 expressions, even though all implementations shall support them. ---- Change: 6363 3. A non-matching list expression begins with a circumflex ('^'), and specifies a list that shall 6364 match any character or collating element except for the expressions represented in the list 6365 after the leading circumflex. For example, "[^abc]" is an RE that matches any character 6366 or collating element except the characters 'a', 'b', or 'c'. ---- to: 6363 3. A non-matching list expression begins with a circumflex ('^'), and specifies a list that shall | match any character except for the expressions represented in the list 6365 after the leading circumflex. For example, "[^abc]" is an RE that matches any character | except the characters 'a', 'b', or 'c'. | It is unspecified whether a non-matching list | expression matches multi-character collating | elements that are not matched by the | expressions. ---- Change: 6402 7. A range expression represents the set of collating elements that fall between two elements 6403 in the collating element order of the current locale, inclusive. ---- to: | 7. In the POSIX locale, a range expression represents | the set of collating elements that are not less | than the starting range point and not greater than | the ending range point. In other locales, a range | expression represents an unspecified set of | collating elements. ---- Remove: 6405 Range expressions shall not be used in portable applications because their behavior is 6406 dependent on the collating sequence. ---- Change: 6413 The ending range point 6414 shall collate equal to or higher than the starting range point; otherwise, the expression is 6415 treated as invalid. The order used is the order in which the collating elements are specified 6416 in the current collation definition. One-to-many mappings (see the description of 6417 LC_COLLATE in Section 7.3.2 (on page 155)) are not performed. For example, assuming 6418 that the character eszet ('_') is placed in the collation sequence after 'r' and 's', but 6419 before 't' and that it maps to the sequence "ss" for collation purposes, then the 6420 expression "[r-s]" matches only 'r' and 's', but the expression "[s-t]" matches 6421 's', '_', or 't'. ---- to: | The represented set of collating elements shall be nonempty; | otherwise, the expression is treated as invalid. _____________________________________________________________________________ objection Enhancement Request Number 166 ajosey@opengroup.org Bug in XBDd4 9.3.5 (rdvk# 49) {tog.aug31.4} Thu, 31 Aug 2000 09:27:30 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6347 Section: 9.3.5 Problem: wording change caused loss of strict conformance requirement for applications. Action: change "Portable applications" -> "Strictly conforming applications" _____________________________________________________________________________ objection Enhancement Request Number 167 gwc@unisoft.com BUG in XBDd4 (RE collating elements) (rdvk# 42) {gwc RE collating elements} Thu, 24 Aug 2000 12:05:10 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6373-6380 Section: 9.3.5 Problem: There are two problems in item 4 on this page concerning collating elements in bracket expressions. 1. In the text "For example, if the string ch is a collating element in the current collation sequence with the associated collating symbol , the expression [[.ch.]] shall be treated ...", using the name and referring to it in this way suggests an association between the name and the "ch" in "[[.ch.]]", but no such association exists. Also, the way the term "collating symbol" is used here is problematic because it has different meanings in the context of bracket expressions and the context of locale definitions, but both are used in this paragraph. (Indeed this paragraph starts by defining the meaning of "collating symbol" in the context of bracket expressions.) 2. The text "if the collating element has no characters associated with it (for example, see the symbol in the example collation definition ..." is redundant at best, erroneous and misleading at worst, because it is not possible to define a collating element that has no characters associated with it. Note that in the cited example, is defined using the collating-symbol keyword, and so "does not represent any collating element" (page 157 line 4631). Action: On lines 6373-6374 replace the text "in the current collation sequence with the associated collating symbol " with the following: defined using the line collating-element from "" in the locale definition On lines 6378-6380 delete the text beginning "or if the collating element has no characters" and ending "(on page 157))". _____________________________________________________________________________ objection Enhancement Request Number 168 ajosey@opengroup.org Bug in XBDd4 9.3.5 (rdvk# 50) {tog.aug31.3} Thu, 31 Aug 2000 09:26:54 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6405 Section: 9.3.5 Problem: wording change caused loss of strict conformance requirement for applications. Action: change "portable applications" -> "strictly conforming applications" _____________________________________________________________________________ objection Enhancement Request Number 169 gwc@unisoft.com BUG in XBDd4 (RE collating elements) (rdvk# 43) {gwc RE grammar} Thu, 24 Aug 2000 12:05:10 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206-209 Line: 6634-6800 Section: 9.5 Problem: There is no provision for multi-character collating elements in the RE grammar. Also, the name "one_character_RE" is misleading - it should be changed to match the heading text to which it corresponds ("9.3.1 BREs Matching a Single Character or Collating Element"). Action: On line 6634 change "COLL_ELEM" to "COLL_ELEM_SINGLE". After line 6634 add the line: COLL_ELEM_MULTI Any multi-character collating element. On line 6689 change "COLL_ELEM" to "COLL_ELEM_SINGLE COLL_ELEM_MULTI". On lines 6716 and 6720 change "one_character_RE" to "one_char_or_coll_elem_RE". On lines 6759, 6762 and 6765 change "COLL_ELEM" to "COLL_ELEM_SINGLE". After line 6762 add the line: | Open_dot COLL_ELEM_MULTI Dot_close After line 6765 add the line: | Open_equal COLL_ELEM_MULTI Equal_close On lines 6794 and 6800 change "one_character_ERE" to "one_char_or_coll_elem_ERE". _____________________________________________________________________________ Comment Enhancement Request Number 170 al.simons@compaq.com BUG in XBDd4 (rdvk# 44) [Simons-Compaq-1] Wed, 23 Aug 2000 14:37:29 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: withdrawn by originator and refiled against XRAT _____________________________________________________________________________ Page: 207 Line: 6888-6889 Section: 9.3.6 Problem: Example is missing some text (or diacritical marks). Reproducing (as best I can using ASCII) the relevant text on these lines, it says: defines 'a as a variant of 'a', while another defines it as a letter following 'z', then the expression "[a-z]" 1) There is a missing close single quote after the first a. 2) the letters a are not distinguished from each other by diacritical marks. Action: Add quote and distinguish the letters a, for instance, as follows (I will use the pair "`a" to indicate an a with some form of diacritical mark). defines '`a' as a variant of 'a', while another defines it as a letter following 'z', then the expression "[`a-z]" _____________________________________________________________________________ objection Enhancement Request Number 171 ajosey@opengroup.org Bug in XBDd4 10.1 (rdvk# 48) {tog.aug31.5} Thu, 31 Aug 2000 09:28:04 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 211 Line: 6825 Section: 10.1 Problem: wording change caused loss of strict conformance requirement for applications. Action: change "Portable applications" -> "Strictly conforming applications" _____________________________________________________________________________ Objection Enhancement Request Number 172 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 74) [DST-19] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 211 Line: 6831 Section: 10.1 Problem: This use of "cannot" is not an observation, it's a requirement. (No where else that I know of is /tmp discussed, and thus the explicit non-guarantee doesn't follow from anything else.) Action: cannot -> shall not. [Ed recommendation: Accept [note that the line number was corrected from 6301 to 6831]] _____________________________________________________________________________ Editorial Enhancement Request Number 173 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 120) [DWC-698] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 227 Line: 7414-7415 Section: 12.1 Problem: (utility conventions: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters," on P227, L7414-7415 to "s,". _____________________________________________________________________________ Editorial Enhancement Request Number 174 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 121) [DWC-699] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 227 Line: 7426 Section: 12.1 Problem: (utility conventions: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters." on P227, L7426 to "s.". _____________________________________________________________________________ Editorial Enhancement Request Number 175 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 122) [DWC-700] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 230 Line: 7530 Section: 12.2 Problem: (utility syntax guidelines: character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P230, L7530 to "s". |". _____________________________________________________________________________ Editorial Enhancement Request Number 176 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 168) [DWC-760] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 234 Line: 7662 Section: arpa/inet.h Problem: (:) The line "The following shall be declared as functions, defined as macros, or both" might avoid misinterpretation with the use of "either". Action: Change the line to read "The following shall either be declared as functions, defined as macros, or both." _____________________________________________________________________________ Objection Enhancement Request Number 177 adjg@eng.sun.com BUG in XBDd4 (rdvk# 54) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete functions "inet_lnaof(), inet_makeaddr(), inet_netof(), inet_network()". we'll also need to remove these pages from XSH _____________________________________________________________________________ Page: 234 Line: 7672-5 Section: arpa/inet.h Problem: These functions are legacy, but not so marked. Action: Shade these functions legacy. _____________________________________________________________________________ Objection Enhancement Request Number 178 adjg@eng.sun.com BUG in XBDd4 (rdvk# 55) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 234 Line: 7677-9 Section: arpa/inet.h Problem: For ease of portability, new programs, even those targeting IPv4 implementations should use the new address formatting routines inet_ntop() and inet_pton(), so they should not be marked IP6. Action: Remove the IP6 shading. _____________________________________________________________________________ Objection Enhancement Request Number 179 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 169) [DWC-761] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 235 Line: 7700-7703 Section: assert.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, there are no requirements beyond what is defined by the ISO C standard. Action: Change the text to read "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 180 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 75) [DST-20] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 235 Line: 7711 Section: assert.h Problem: Shallification. Action: "is implemented" -> "shall be implemented". _____________________________________________________________________________ Objection Enhancement Request Number 181 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 170) [DWC-762] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 236 Line: 7731-7734 Section: complex.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, there are no requirements beyond what is defined by the ISO C standard. Action: Change the text to read "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 182 drepper@redhat.com Bug in XBDd4 (rdvk# 1) {ud-1} Tue, 1 Aug 2000 17:30:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 236 Line: 7735 Section: Problem: The text currently says: The header shall define the following constants: and then goes on to introduce `complex'. But `complex' is a macro expanding to a name of a type. Also, it is not clear from this text that all complex, _Complex_I, imaginary, _Imaginary_I, and I are macros which can be undefined and redefined if necessary. Action: Replace line 7735 with: The header shall define the following macros: Replace lines 7744-7745 with: The macros imaginary and _Imaginary_I shall be defined if the implementation supports imaginary types. Replace line 7746 with: An application may undefine and then, perhaps, redefine the complex, imaginary, and I macros. [Ed recommendation: Accept as marked below: Replace line 7735 with: The header shall define the following macros: Replace lines 7744-7745 with: The macros imaginary and _Imaginary_I shall be defined if and only if the implementation supports imaginary types. Replace line 7746 with: An application may undefine and then, perhaps, redefine the complex, imaginary, and I macros. ] _____________________________________________________________________________ Objection Enhancement Request Number 183 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 171) [DWC-763] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_182 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 236 Line: 7735-7745 Section: complex.h Problem: () On line 7735, there is a requirement that the header define a number of constants, yet on lines 7744-7745, the statement is made that the constants imaginary and _Imaginary_I shall be defined only if the implementation supports imaginary types. Make this more concise without contradictions. Action: Insert after P236, L7738: If the implementation supports imaginary types, the header shall define the following constants:" Insert after P236, L7741: The header shall define the following constants: _____________________________________________________________________________ editorial Enhancement Request Number 184 Clive D.W. Feather BUG in XBDd4 (rdvk# 8) [CDWF 3] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 236 Line: 7737,7740 Section: complex.h Problem: _Complex and _Imaginary are keywords and so should be in the same font as const and float. Action: Fix the font. _____________________________________________________________________________ objection Enhancement Request Number 185 Clive D.W. Feather BUG in XBDd4 (rdvk# 9) [CDWF 4] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 237 Line: 7782-7784 Section: complex.h Problem: The functions catanh etc are repeated; the functions ctanh etc are missing. Action: Change the function names from catanh to ctanh. _____________________________________________________________________________ editorial Enhancement Request Number 186 Clive D.W. Feather BUG in XBDd4 (rdvk# 10) [CDWF 5] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 238 Line: 7791-7814 Section: complex.h Problem: The functions on lines 7791-7793, 7800-7805, and 7812-7814 are hard to read. Action: Change the spacing so that the function name is underneath the other function names, not under the "complex" pseudo-keyword. _____________________________________________________________________________ Objection Enhancement Request Number 187 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 172) [DWC-764] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: note to editors this is a different header block _____________________________________________________________________________ Page: 242 Line: 7927-7930 Section: ctype.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, only a few symbols listed are extensions to the ISO C header. Action: Change the text to read "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header. ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 188 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 173) [DWC-765] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 244 Line: 7984 Section: dirent.h Problem: () This line contains a statement "the number of bytes preceding the terminating null byte does not exceed {NAME_MAX}". This was changed from the text in XSH5 which stated that the number of bytes "will not exceed {NAME_MAX}". Action: Change "does not" on P244, L784 to "shall not". _____________________________________________________________________________ Objection Enhancement Request Number 189 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 174) [DWC-766] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 247 Line: 8071-8074 Section: errno.h Problem: () While additional errnos beyond what is defined by the ISO C standard have been added to this page, the ISO C standard explicitly allows the additional names that begin with "E". Therefore, no additional feature test macros are required in order to use these extensions to the ISO C standard. Action: Change the text to read: "Some of the functionality described on this reference page extends the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". _____________________________________________________________________________ objection Enhancement Request Number 190 Clive D.W. Feather BUG in XBDd4 (rdvk# 12) [CDWF 7] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 247 Line: 8074 Section: errno.h Problem: The lack of CX marking on symbols implies that they are provided as part of C99 when in fact they are not. When most symbols in a header are currently unshaded but not part of C99, this should be done by adding an explicit comment. Where only a few symbols would have to be shaded, this should be done by CX shading that symbol. Action: Insert a CX-shaded paragraph after page 247 line 8074 section errno.h: The ISO C Standard only requires the symbols EDOM, EILSEQ, and ERANGE to be defined. Insert a CX-shaded paragraph after page 281 line 9108 section limits.h: Many of the symbols listed here are not defined by ISO/IEC 9899:1999. Such symbols are not shown as CX shaded. Insert a CX-shaded paragraph after page 339 line 11258 section signal.h: The ISO C Standard only requires the signal names SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM to be defined. Put CX shading on the following symbol definitions or references: page 296 line 9773 section locale.h: LC_MESSAGES page 336 line 11176 section setjmp.h: sigjmp_buf page 336 line 11180 section setjmp.h: siglongjmp page 336 line 11186 section setjmp.h: sigsetjmp page 338 line 11224 section signal.h: SIG_HOLD page 338 line 11229 section signal.h: sigset_t page 338 line 11230 section signal.h: pid_t page 340 line 11301-11309 section signal.h: struct sigaction page 340 line 11313 section signal.h: SA_NOCLDSTOP page 340 line 11314 section signal.h: SIG_BLOCK page 340 line 11316 section signal.h: SIG_UNBLOCK page 340 line 11318 section signal.h: SIG_SETMASK page 341 line 11343 section signal.h: siginfo_t page 341 line 11345 section signal.h: si_signo page 341 line 11348 section signal.h: si_code page 342 line 11395 section signal.h: SI_USER page 342 line 11396 section signal.h: SI_QUEUE page 342 line 11397 section signal.h: SI_TIMER page 342 line 11398 section signal.h: SI_ASYNCIO page 342 line 11340 section signal.h: SI_MESGQ page 343 line 11421 section signal.h: kill page 343 line 11423 section signal.h: pthread_kill page 343 line 11424 section signal.h: pthread_sigmask page 343 line 11426 section signal.h: sigaction page 343 line 11428 section signal.h: sigaddset page 343 line 11430 section signal.h: sigdelset page 343 line 11431 section signal.h: sigemptyset page 343 line 11432 section signal.h: sigfillset page 343 line 11436 section signal.h: sigismember page 343 line 11439 section signal.h: sigpending page 343 line 11440 section signal.h: sigprocmask page 343 line 11445 section signal.h: sigsuspend page 343 line 11448 section signal.h: sigwait page 358 line 11968 section stdio.h: L_ctermid page 359 line 11995 section stdio.h: ctermid page 359 line 11997 section stdio.h: fdopen page 359 line 12004 section stdio.h: fileno page 359 line 12027 section stdio.h: pclose page 359 line 12029 section stdio.h: popen page 363 line 12207 section stdlib.h: unsetenv page 428 line 14336 section time.h: gmtime_r page 428 line 14353 section time.h: tzset page 428 line 14357 section time.h: tzname _____________________________________________________________________________ objection Enhancement Request Number 191 Clive D.W. Feather BUG in XBDd4 (rdvk# 11) [CDWF 6] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 247 Line: 8075 Section: errno.h Problem: The values for errno must be positive. Action: Change "non-zero values" to "positive values". [Ed recommendation: Accept as marked, this is a c99 reqt, which has changed from c89 where it previously said nonzero,so: Make the change above, and add to CH, "Values for errno are now required to be distinct positive values rather than non-zero values, this change is for alignment with the ISO/IEC 9899:1999 standard." ] _____________________________________________________________________________ Objection Enhancement Request Number 192 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 175) [DWC-767] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 254 Line: 8305-8308 Section: fenv.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, only a few symbols listed are extensions to the ISO C header. Action: Change the text to read "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 193 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 176) [DWC-768] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "flaoting-point on P254, L8326 to "floating-point". rework the page so we have text followed by the constants in blocks _____________________________________________________________________________ Page: 254 Line: 8320-8339 Section: fenv.h Problem: () On line 8320, there is a requirement that the header define a number of constants, yet on line 8325 and again on line 8336, exceptions are noted if the implementation does not provide support for certain functions. Make this more concise without contradictions. There is also a misspelled phrase ("flaoting-point") that this fixes. Action: Change "flaoting-point on P254, L8326 to "floating-point". Insert after line 8324 "If the implementation supports floating-point exception by means of...fetesetexcept()," (copied from P254, L8327-8328), the header shall define the following constants". A similar statement specific to the constants on lines 8336 - 8339 should be inserted just before line 8336. The line on 8320 should then be duplicated just before line 8340. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 194 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 166) [DWC-758] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 254 Line: 8340 Section: fenv.h Problem: (: description) C99 uses "default floating-point environment" here. This draft just has "floating-point environment" here. The current wording here implies that the default FPE can't be changed, and then describes the functions that do change the FPE. Action: Change "floating-point environment" on P254, L8340 to "default floating- point environment". ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 195 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 177) [DWC-769] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 254 Line: 8341 Section: fenv.h Problem: () There is an extra paren at the end of the sentence on line 8341. Action: Change "to const-qualified fenv_t)." on P254, L8341 to "to const-qualified fenv_t." _____________________________________________________________________________ objection Enhancement Request Number 196 Clive D.W. Feather BUG in XBDd4 (rdvk# 19) [CDWF 14] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Do as noted, add to change history: The return types for (list funcs) is changed from void to int for aligmnment with ISO C99 defect report 202. _____________________________________________________________________________ Page: 255 Line: 8346-8356 Section: fenv.h Problem: At a very late stage in the development of C99 it was realized that it should be possible for various fenv.h functions to fail - even if a flag is supported by the implementation, it isn't always possible to set it. A Technical Corrigendum - based on Defect Report 202 - is currently working its way through the system. This has the effect of changing the return type of several functions from "void" to "int". Action: Change the return type of the following functions from "void" to "int": feclearexcept fegetexceptflag feraiseexcept fesetexceptflag fegetenv fesetenv feupdateenv (That is, all the functions with a void return type). The wording beginning on line 8455 may need adjustment accordingly. _____________________________________________________________________________ Objection Enhancement Request Number 197 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 178) [DWC-770] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 255, Line: 8375-8391 Section: fenv.h Problem: (: FENV_ACCESS pragma) The text on P255, O8375-8391 (up to "For example:"), is a normative requirement in C99 (section 7.6.1), It should be normative here as well. Action: Move P255, L8375-8391, except for "For example:" to come before L8357. ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 198 Clive D.W. Feather BUG in XBDd4 (rdvk# 14) [CDWF 9] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 257 Line: 8440 Section: fenv.h Problem: "fexcept_t" is missing the final t. Action: Fix the spelling. [Ed recommendation: Accept , note the line number in submitted rdvk was corrected to 8440 ] _____________________________________________________________________________ objection Enhancement Request Number 199 Clive D.W. Feather BUG in XBDd4 (rdvk# 20) [CDWF 15] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 257 Line: 8848-8854 Section: fenv.h Problem: C99 does not allow these names to be defined, since they are reserved. Action: CX shade the wording from "An application might explicitly define" to the end of the paragraph. [Ed recommendation: Note, we assume line numbers are meant to be 8448-8454. REJECT, this text is non-normative, we do not further shade rationale sections.] _____________________________________________________________________________ Objection Enhancement Request Number 200 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 179) [DWC-771] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 259 Line: 8494-8497 Section: float.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, there are no requirements beyond what is defined by the ISO C standard. Action: Change the text to read "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 201 Clive D.W. Feather BUG in XBDd4 (rdvk# 15) [CDWF 10] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 261 Line: 8534-8535 Section: float.h Problem: Some of the dagger marks are in column 2 but should be in column 3. There are other infelicities in the presentation. There are no line numbers. Action: Split the table into two. The first table holds those values that have an entry in column three. The second is introduced by: The macro names given in the following list are defined as expressions whose values can be derived from properties of the floating point representation. and place in it those values that have daggers - this table would not have a third column. In any case, where there are three names in the first column they should be bundled together so that the description clearly applies to all three. _____________________________________________________________________________ Comment Enhancement Request Number 202 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 180) [DWC-772] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "flags and ... are defined:" on P265, L8617-8618 to "flags:". OB shade 8623 (and remove LEGACY), Change the description for FNM_NOSYS to "Reserved", check CH. _____________________________________________________________________________ Page: 265 Line: 8617-8618 Section: fnmatch.h Problem: () The requirements what is to be defined by does not match the other headers in this draft. Action: Change "flags and ... are defined:" on P265, L8617-8618 to "flags:". Add after P265, L8622: The header shall also define the following macro which could have been used as a return value by the fnmatch() function in a prior revision of this standard: Change "None." on P265, L8630 to: The fnmatch() function was optional in an earlier revision of this standard. Now that fnmatch() is required, it will never return FNM_NOSYS. FNM_NOSYS is still required by this revision as a conversion aid for applications that were checking to be sure fnmatch() was fully functional, but may disappear in a later revision. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 203 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 181) [DWC-773] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: do as per fnmatch.h in ERN 202 but for GLOB_NOSYS _____________________________________________________________________________ Page: 268 Line: 8727 Section: glob.h Problem: (: GLOB_NOSYS) The fnmatch() and glob() functions were not required to be fully implemented in POSIX.2-1992. They are fully required in this revision. In , FNM_NOSYS is marked LEGACY. GLOB_NOSYS should be marked the same way here. Action: Add " (LEGACY)" to the end of P268, L8727. Change "None." on P269, L8738 to: The glob() function was optional in an earlier revision of this standard. Now that glob() is required, it will never return GLOB_NOSYS. GLOB_NOSYS is still required by this revision as a conversion aid for applications that were checking to be sure glob() was fully functional, but may disappear in a later revision. ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 204 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 182) [DWC-774] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8830 Section: inttypes.h Problem: () The header is derived from ISO C, yet there is not text at the beginning of the page to indicate this. Action: Add "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 205 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 76) [DST-21] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8834 Section: inttypes.h Problem: I think you meant "stdint.h". Action: "stdin" -> "stdint". (One does wonder if a less error-prone name could be chosen.) _____________________________________________________________________________ objection Enhancement Request Number 206 Clive D.W. Feather Integer types (rdvk# 218) [CDWF-104] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Move these lines to stdint.h and rework 11776 - 11777, modelled on 11785-11794 without the "least": (CX The following types are required:) A note about this requirement is added to the global reviewers notes for D5 highlighting the implications of requiring fixed width types. _____________________________________________________________________________ Page: 273 Line: 8837-8844 Section: inttypes.h Problem: Defining the symbols int8_t to uintptr_t inclusive make certain assumptions about the implementation, such as that it has 8 bit bytes. Since this is not a requirement, these symbols should not be required. In any case, they are described (correctly) in stdint.h. Action: Delete these lines. _____________________________________________________________________________ objection Enhancement Request Number 207 Clive D.W. Feather Integer types (rdvk# 219) [CDWF-105] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move 8845-8857 to after text added in ERN 206 (i.e into stdint.h) _____________________________________________________________________________ Page: 273 Line: 8845-8857 Section: inttypes.h Problem: This text does not match the descriptions of the environments on page 2429. The symbols involved also do not belong here, but in stdint.h. Action: Delete these lines. *IF* you wish to say something about these matters, then the following requirements can be derived from page 2429 table 4-4. They should be placed on page 354, following line 11831, and be CX shaded: Environment Types that must be defined _POSIX_V6_ILP32_OFF32 int32_t uint32_t _POSIX_V6_ILP32_OFFBIG int32_t uint32_t _POSIX_V6_LP64_OFF64 int32_t uint32_t int64_t uint64_t _POSIX_V6_LPBIG_OFFBIG none _____________________________________________________________________________ objection Enhancement Request Number 208 Clive D.W. Feather BUG in XBDd4 (rdvk# 37) [CDWF 32] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8858 Section: inttypes.h Problem: The reference to __STDC_FORMAT_MACROS in C99 only applies to C++ compilers. Action: Delete "If __STDC_FORMAT_MACROS is defined before is included, then". _____________________________________________________________________________ objection Enhancement Request Number 209 Clive D.W. Feather Integer types (rdvk# 220) [CDWF-106] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_208 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8858-8859 Section: inttypes.h Problem: The requirement for __STDC_FORMAT_MACROS to be defined applies to C++, not to C99. A C99 program can rely on these macros even where the symbol is note defined. Action: Delete the first sentence: "If ... shall be defined.". _____________________________________________________________________________ editorial Enhancement Request Number 210 Clive D.W. Feather BUG in XBDd4 (rdvk# 5) [CDWF 33] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8865-8882 Section: inttypes.h Problem: It is unclear that the last "N" in these names (but not the N in "SCN") is a metaidentifier. Action: Change the relevant "N"s to italic font. [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 211 Clive D.W. Feather BUG in XBDd4 (rdvk# 7) [CDWF 2] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_212 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 276 Line: 8940-8943 Section: iso646.h Problem: This boilerplate text does not apply to this header, since it exactly matches the C99 requirements. Action: Delete the boilerplate text here and also at: Page 348 line 11611-11614: section stdarg.h Page 350 line 11683-11686: section stdbool.h Page 351 line 11710-11713: section stddef.h Page 352 line 11743-11746: section stdint.h Page 423 line 14116-14119: section tgmath.h [Ed recommendation: REJECT, although the same , the information is duplicated here and in C99, this boiler shows the deference should the two diverge for some reason] _____________________________________________________________________________ Objection Enhancement Request Number 212 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 183) [DWC-775] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Do the action below, but check the following headers: stdarg.h,stdbool.h,stddef.h,stdint.h,tgmath.h _____________________________________________________________________________ Page: 276 Line: 8940-8943 Section: iso646.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, there are no requirements beyond what is defined by the ISO C standard. Action: Change the text to read "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". _____________________________________________________________________________ Editorial Enhancement Request Number 213 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 184) [DWC-776] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 280 Line: 9099 Section: libgen.h Problem: () The LEGACY declaration extern char * __loc1 was removed along with the historical regcmp() and regex() functions, yet the change history does not note this. Action: Add change history for Issue 6 to note removal of __loc1, regcmp() and regex(). _____________________________________________________________________________ Objection Enhancement Request Number 214 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 185) [DWC-777] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 281 Line: 9105-9108 Section: limits.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, only a few symbols listed are extensions to the ISO C header. Action: Change the text to read "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header. _____________________________________________________________________________ Objection Enhancement Request Number 215 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 186) [DWC-778] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 296 Line: 9737-9740 Section: locale.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, there are no requirements beyond what is defined by the ISO C standard. Action: Change the text to read "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C Standard". _____________________________________________________________________________ editorial Enhancement Request Number 216 Clive D.W. Feather BUG in XBDd4 (rdvk# 21) [CDWF 16] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 297 Line: 9800 Section: locale.h Problem: There are spaces missing around "is". Action: Insert the spaces. _____________________________________________________________________________ Objection Enhancement Request Number 217 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 187) [DWC-779] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 298 Line: 9811-9814 Section: math.h Problem: () The text referencing the ISO C standard implies that everything on this page is an extension to the ISO C standard. This is not true, and in fact, only a few symbols listed are extensions to the ISO C header. Action: Change the text to read "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header. _____________________________________________________________________________ objection Enhancement Request Number 218 Clive D.W. Feather BUG in XBDd4 (rdvk# 16) [CDWF 11] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note , that a defect report against C99 has been filed (we need the defect report number) _____________________________________________________________________________ Page: 298 Line: 9816-9817 Section: math.h Problem: The term "floating type" includes imaginary and complex types. This is a defect in C99 which I have raised with WG14, and there is general consensus that it needs fixing. Action: Change "floating type" to "real-floating type". _____________________________________________________________________________ editorial Enhancement Request Number 219 Clive D.W. Feather BUG in XBDd4 (rdvk# 17) [CDWF 12] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 298 Line: 9823 Section: math.h Problem: The term "real-floating" should be in a different font, since it is not a C keyword but a concept. Action: Change the font. _____________________________________________________________________________ Editorial Enhancement Request Number 220 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 77) [DST-22] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: we will spell out infinity _____________________________________________________________________________ Page: 299 Line: 9855 Section: math.h Problem: line 9855 spells "infinity" using the lazy-8 symbol. lines 9857 and 9860 use the English word. Action: Pick either, but use only one in all these (and other) situations. _____________________________________________________________________________ editorial Enhancement Request Number 221 Clive D.W. Feather BUG in XBDd4 (rdvk# 18) [CDWF 13] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9857,9860 Section: math.h Problem: Line 9855 uses an infinity symbol but these two lines do not. Action: Be consistent. [Ed recommendation: Accept (editors choice)] _____________________________________________________________________________ editorial Enhancement Request Number 222 pete.forman@westgeo.com Bug in XBDd4 (rdvk# 85) {PWF20000919/1} Tue, 19 Sep 2000 10:41:39 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9859 Section: Problem: HUGE_VALD should be HUGE_VALL for consistency with C99. This is probably just a typo. Action: Replace "HUGE_VALD" with "HUGE_VALL" in lines 9859 and 9860 (two instances). _____________________________________________________________________________ Editorial Enhancement Request Number 223 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 164) [DWC-757] Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_224 Reject____ Rationale for rejected or partial changes: ignore this request it is the header to 224 _____________________________________________________________________________ Page: 299, Line: 9859,9860 Section: math.h Problem: (: description) _____________________________________________________________________________ Editorial Enhancement Request Number 224 Don.Cragun@eng.sun.com Bug in XBD6d4 (rdvk# 165) [SUN] HUGE_VALD is Tue, 26 Sep 2000 23:08:45 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_222 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9859-9860 Section: specified here, but doesn't appear in C99. HUGE_VALL is specified in C99, but doesn't appear here. Action: Change "HUGE_VALD" on P299, L9859 to "HUGE_VALL". Change "HUGE_VALD" on P299, L9860 to "HUGE_VALL". ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 225 Clive D.W. Feather BUG in XBDd4 (rdvk# 24) [CDWF 19] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9878-9885 Section: math.h Problem: The paragraph is hard to parse, and one macro name is misspelled. Action: Proposed alternative wording: The following optional macros indicate whether the fma() family of functions are fast compared with direct code. FP_FAST_FMA FP_FAST_FMAF FP_FAST_FMAL The FP_FAST_FMA macro shall be defined to indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. The other macros have the equivalent meaning for the float and long double versions. _____________________________________________________________________________ editorial Enhancement Request Number 226 Clive D.W. Feather BUG in XBDd4 (rdvk# 25) [CDWF 20] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 300 Line: 9894-9902 Section: math.h Problem: The paragraph is hard to parse - it appears as though the macro name on line 9902 is nothing to do with the rest of it. Action: Split line 9895 at the full stop and insert line 9902 at that point: ... OR of both. math_errhandling The value of ... [Ed recommendation: Accept as marked, as above, except that the full stop then should become a semi-colon] _____________________________________________________________________________ objection Enhancement Request Number 227 Clive D.W. Feather BUG in XBDd4 (rdvk# 22) [CDWF 17] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 300 Line: 9907 Section: math.h Problem: Several function names have been XSI shaded even though they are required by the C Standard. Action: Remove the shading from: page 300 line 9907 section math.h: acosh page 300 line 9913 section math.h: asinh page 300 line 9922 section math.h: atanh page 300 line 9926 section math.h: cbrt page 301 line 9941 section math.h: erf page 301 line 9942 section math.h: erfc page 301 line 9953 section math.h: expm1 page 301 line 9980 section math.h: hypot page 301 line 9983 section math.h: ilogb page 302 line 9993 section math.h: lgamma page 302 line 10000 section math.h: log1p page 302 line 10006 section math.h: logb page 302 line 10032 section math.h: nextafter page 302 line 10041 section math.h: remainder page 303 line 10047 section math.h: rint page 360 line 12042 section stdio.h: snprintf page 360 line 12053 section stdio.h: vsnprintf _____________________________________________________________________________ objection Enhancement Request Number 228 Clive D.W. Feather BUG in XBDd4 (rdvk# 23) [CDWF 18] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 301 Line: 9986 Section: math.h Problem: The symbol isnan should not be listed here, as it is already (correctly) listed on page 298 line 9827. Action: Delete the line. _____________________________________________________________________________ Objection Enhancement Request Number 229 adjg@eng.sun.com BUG in XBDd4 (rdvk# 57) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10328 Section: netdb.h Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), and getipnodebyname(). _____________________________________________________________________________ Objection Enhancement Request Number 230 adjg@eng.sun.com BUG in XBDd4 (rdvk# 58) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 312 Line: 10390-9 Section: netdb.h Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), getipnodebyname() and freehostent(). _____________________________________________________________________________ Objection Enhancement Request Number 231 adjg@eng.sun.com BUG in XBDd4 (rdvk# 59) [] Thu, 14 Sep 2000 17:18:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 313 Line: 10430 Section: netdb.h Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove line 10430. _____________________________________________________________________________ comment Enhancement Request Number 232 drepper@redhat.com Bug in XBDd4 (rdvk# 53) {ud-6} Mon, 11 Sep 2000 19:28:23 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below, but no parameter names in a header file are needed the shading should be XSI (unless an outstanding interp closes in 30 days positively in which case TSA?) _____________________________________________________________________________ Page: 323 Line: 10718,10739 Section: Problem: The pthread_attr_getstack() and pthread_attr_setstack() functions are not mentioned in the header. Action: Add before line 10718: int pthread_attr_getstack(const pthread_attr_t *restrict attr, void **restrict stackaddr, size_t *restrict stacksize); Add before line 10730: int pthread_attr_setstack (pthread_attr_t *attr, void *stackaddr, size_t __stacksize); The shading marker for both should probably TSA. _____________________________________________________________________________ objection Enhancement Request Number 233 ajosey@opengroup.org Bug in XBDd4 pthread.h (rdvk# 2) {pasc-1003.1-86} Wed, 2 Aug 2000 12:04:34 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 325 Line: 10834 Section: pthread.h Problem: Finalised PASC Interpretation 1003.1-86 points out several defects in the namespace rules for pthread.h. The action below differs from that in section 11 (the submitters suggestion). I believe the action here is better and in keeping with the approach used elsewhere in the specification. Action: Remove the XSI shading at lines 10834-10835. Add to Change History: IEEE PASC Interpretation 1003.1 #86 allowing the symbols from sched.h and time.h to be made visible when pthread.h is included. Previously this was an XSI extension. _____________________________________________________________________________ objection Enhancement Request Number 234 ajosey@opengroup.org Bug in XBDd4 signal.h (rdvk# 3) {pasc-1003.1-85} Wed, 2 Aug 2000 12:04:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 343 Line: 11450 Section: signal.h Problem: Finalised PASC Interpretation 1003.1-85 points out a defect in the namespace rules for signal.h. Action: Add after line 11450: Inclusion of the header may make visible all symbols from the header. Add to Change History: IEEE PASC Interpretation 1003.1 #85 is applied adding the statement that symbols from may be made visible when is included. [Ed recommendation: Accept as marked, do above but the text added at 11450 should be CX] _____________________________________________________________________________ Editorial Enhancement Request Number 235 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 78) [DST-23] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (roman) _____________________________________________________________________________ Page: 350 Line: 11688 Section: stdboo.h Problem: Font. Action: bool, true, false, and __bool_true_false_are_defined are constant literals (the same as NULL on the next page) and thus should be in ordinary font. _____________________________________________________________________________ editorial Enhancement Request Number 236 Clive D.W. Feather BUG in XBDd4 (rdvk# 6) [CDWF 1] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 351 Line: 11717 Section: stddef.h Problem: The term "integral" is used to mean an integer. The C Standard carefully changed all such uses of the term to "integer. Action: Change "integral" to "integer" throughout all documents where it means an integer number. Obviously not where it means something else like calculus. page 126 line 3504 page 263 line 8562 page 296 line 9777 page 315 line 10506 page 338 line 11248 page 339 line 11257 page 351 line 11717 page 358 line 11958 page 358 line 11976 page 361 line 12088 page 361 line 12090 page 390 line 13045 page 390 line 13052 page 391 line 13073 page 391 line 13083 page 391 line 13088 _______________________________________________________________________________ objection Enhancement Request Number 237 gwc@unisoft.com BUG in XBDd4 (preserve integral types) (rdvk# 39) {gwc preserve integral types} Wed, 16 Aug 2000 11:56:19 +0100 _______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The review team believes that accepting the proposed change would decrease consensus. Adding additional restrictions to the types limits future extensions, and that some of this is a quality of implementation issue, and that existing practise may already be at odds with the proposal. _______________________________________________________________________________ Page: 351 Line: 11721-11727 Section: stddef.h Problem: The change in draft 4 to C99 integer type terminology has had the side effect of altering the range of types that implementations can use to define the "_t" types that were previously required to be "integral" types (in C89 terminology). Since there is no direct equivalent in C99 terminology for the C89 term "integral type", in order to preserve the current UNIX98/POSIX96 requirements for these "_t" types an explicit restriction to allow only a subset of the integer types needs to be added. Giving an exact list of the types that were allowed in UNIX98/POSIX96 would perhaps be too restrictive - the important thing is to restrict the widest type allowed, so I propose that all types previously required to be C89 integral types should now be required to be "integer types no wider than long int" for signed types, and "unsigned integer types no wider than unsigned long int" for unsigned types (except for rlim_t, since it seems reasonable to want rlim_t to be able to represent the full range of off_t values). It is essential that a restriction of this nature is made for the most frequently used of these "_t" types, otherwise the consequences for portability of existing UNIX/POSIX applications to the new standard would be disastrous. This is because a great deal of existing code assumes, based on the `promise' made in C89, that long int is the widest integer type in C, and therefore that it is safe to convert size_t values to unsigned long int, or ssize_t and pid_t values to long int, for example. Probably the most frequent occurrence is code that prints (or converts to a string) values of type size_t by casting them to unsigned long and using %lu. This has been widely accepted for many years as the "correct" way to format values held in size_t and other integral "_t" types. Even programmers who take the most meticulous care to ensure their code is standards compliant and maximally portable have (until recently) had no qualms about using this method. If existing code that assumes size_t is no wider than unsigned long int is compiled on a system where this is not the case, then the compiler need not provide any indication that a problem exists, and the program may well appear to run properly at first. However, the first time that a size_t value greater than ULONG_MAX is encountered, the program will misbehave, perhaps crashing, but more likely just silently producing incorrect output or corrupting data. Such problems would not be limited to programs that use "large objects", since large size_t values also occur as indicators (e.g. mbstowcs() returns (size_t)-1 on error). Finding and updating all such code would be a very long and difficult task, likely to require much more effort than the work that was done to find and fix any Year 2000 problems in the same code. This is because a much larger proportion of the code would need to be closely examined and/or changed. (Date related code is not all that common, but size_t is very common.) This issue has been debated at length already during the development of the C99 standard. The current status is that defect report 201, which requests a similar restriction on size_t and ptrdiff_t to that proposed here, remains open with "no consensus" for the change. DR201 was submitted by the UK national committee "IST/5/-/14", who actually voted against approving the final draft of C99 because of this problem (and one other, submitted as DR202). Although it looks like no restriction will be added to C99, this does not mean that the same debate for POSIX/UNIX will have a foregone conclusion, as the C Standard has to be implementable on a much wider range of systems than POSIX and UNIX. If no restriction is placed on the width of size_t and ptrdiff_t in the standard(s), many software developers will simply choose not to support systems where these types are wider than long int. Some have stated their intention to perform compile-time checking of the sizes of defined types, e.g. by declaring a dummy array like this: int TEST_size_t[(size_t)-1 <= (unsigned long)-1 ? 1 : -1]; The whole point of having API standards is so that applications can be implemented to the standard and will then work the same on any compliant system without modification (and without the need for system-specific #ifdefs). If we end up in a situation where application writers have to resort to measures like the above to ensure their code cannot be installed on certain compliant systems where they know it would not work, then the standards will have failed in their main objective. Finally, although the actions below are in the form of changes to the current draft, it should be stressed that they do not represent a change to the existing standards. They preserve the "_t" type requirements as (approximately) those of UNIX98 by undoing the side effects of a change in terminology. Allowing a wider range of integer types for size_t etc. is a change of enormous magnitude with major repercussions. It should not be allowed in "by the back door", but should require at least as much careful consideration as was given to the large file issue by the Large File Summit. Action: In the definition of ptrdiff_t on line 11721 change "Signed integer type" to "Signed integer type no wider than long int". In the definition of wchar_t on line 11722 change "Integer type whose range" to "Integer type, no wider than (signed or unsigned) long int, whose range". In the definition of size_t on line 11727 change "Unsigned integer type" to "Unsigned integer type no wider than unsigned long int". Related changes on other pages: page 320 line 10629 section poll.h objection { nfds_t } Change "unsigned integer type" to "unsigned integer type no wider than unsigned long int". page 406 line 13588 section sys/types.h objection { size_t } Change "unsigned integer type" to "unsigned integer type no wider than unsigned long int". page 406 line 13589 section sys/types.h objection { blksize_t pid_t ssize_t } Change "signed integer types" to "signed integer types no wider than long int". page 406 line 13591 section sys/types.h objection { useconds_t } Change "unsigned integer type capable" to "unsigned integer type, no wider than unsigned long int, capable". page 406 line 13592 section sys/types.h objection { suseconds_t } Change "signed integer type capable" to "signed integer type, no wider than long int, capable". page 417 line 13929 section termios.h objection { cc_t speed_t tcflag_t } Change "unsigned integer types" to "unsigned integer types no wider than unsigned long int". page 462 line 15696 section wchar.h objection { wint_t } Change "integer type capable" to "integer type, no wider than long int, capable". _____________________________________________________________________________ comment Enhancement Request Number 238 Clive D.W. Feather Integer types (rdvk# 215) [CDWF-101] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use the boilerplate for where there are changes on the page(there will be after this round of rdvk is applied) _____________________________________________________________________________ Page: 352 Line: 11743-11746 Section: stdint.h Problem: This boilerplate implies there are significant differences between POSIX and C99. In fact there are no differences at all that I can see. Action: Change the boilerplate to the "Any differences are unintended" one. _____________________________________________________________________________ comment Enhancement Request Number 239 Clive D.W. Feather BUG in XBDd4 (rdvk# 28) [CDWF 23] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 352 Line: 11747 Section: stdint.h Problem: The term "width" has a special meaning in C99 which isn't in the XBD terminology. Action: Append a paragraph: Note: the "width" of an integer type is the number of bits used to store its value in a pure binary system; the actual type may use more bits than that (e.g. a 28 bit type could be stored in 32 bits of actual storage). An N bit signed type has values in the range N-1 N-1 N-1 -2 or 1-2 to 2 -1, while an N bit unsigned type has values in N the range 0 to 2 -1. _____________________________________________________________________________ Comment Enhancement Request Number 240 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 79) [DST-24] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add NOTE to end of section to the effect that applications can test for optional types here by using the corresponding limit macro. Make intptr_t and uintptr_t XSI shaded and mandatory. _____________________________________________________________________________ Page: 354 Line: 11823 Section: stdint.h Problem: Optionality of type names is both hard to test for at compile time and not very helpful. In the POSIX context, could these be required? Action: Consider requiring. _____________________________________________________________________________ editorial Enhancement Request Number 241 Clive D.W. Feather BUG in XBDd4 (rdvk# 26) [CDWF 21] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 354 Line: 11853 Section: stdint.h Problem: The superscript should be "N-1". Action: Correct this. _____________________________________________________________________________ Editorial Enhancement Request Number 242 Andries.Brouwer@cwi.nl Bug in XBDd4 (rdvk# 40) [] Wed, 16 Aug 2000 15:40:50 +0200 (MET DST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 356 Line: 11898 Section: omitted Problem: [ should be { Action: Replace "[WINT_MAX}" by "{WINT_MAX}". _____________________________________________________________________________ objection Enhancement Request Number 243 Clive D.W. Feather Integer types (rdvk# 217) [CDWF-103] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add a revnote pending the defect report being confirmed ( we would need to get the defect report number) _____________________________________________________________________________ Page: 356 Line: 11913-11933 Section: stdint.h Problem: It is almost impossible to implement macros like INT8_C without special compiler support. WG14 has recognised this by agreeing changes to the wording that will shortly appear in a Technical Corrigendum. The same changes should be made here. Action: - - on lines 11913, 11928, and 11931 change "integer constants" to "integer constant expressions"; - - after line 11918 add a new paragraph: Each invocation of one of these macros shall expand to an integer constant expression suitable for use in #if preprocessing directives. The type of the expression shall have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. The value of the expression shall be that of the argument. - - change lines 11920 to 11926 (two paragraphs) to: The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t. The macro UINTN_C(value) shall expand to an integer constant expression corresponding to the type uint_leastN_t. For example, if uint_least64_t is a name for the type unsigned long long int, then UINT64_C(0x123) might expand to the integer constant 0x123ULL. _____________________________________________________________________________ objection Enhancement Request Number 244 Clive D.W. Feather Integer types (rdvk# 216) [CDWF-102] Thu, 28 Sep 2000 07:35:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add a revnote pending the defect report being confirmed ( we would need to get the defect report number) _____________________________________________________________________________ Page: 356 Line: 11917 Section: stdint.h Problem: The term "decimal, octal, or hexadecimal constant" has a specific meaning in C99 which I can't find reflected in POSIX. Basically you have left this term undefined. Action: Change "decimal, octal, or hexadecimal constant" to "integer constant" and append to this paragraph: The constant shall have one of the following syntactic forms: * sequence of decimal digits of which the first one is not "0"; * sequence of octal digits of which the first one is "0"; * sequence of hexadecimal digits prefixed with "0x" or "0X". _____________________________________________________________________________ objection Enhancement Request Number 245 Clive D.W. Feather BUG in XBDd4 (rdvk# 29) [CDWF 24] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_244 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 356 Line: 11917-11918 Section: stdint.h Problem: The terms "decimal ... constant" have a specific meaning in C99 which isn't made clear here. Action: Change the text to: The argument in any instance of these macros shall have the textual form of a decimal, octal, or hexadecimal constant (that is, it shall be a sequence of decimal digits not starting with 0, a sequence of octal digits starting with 0, or a sequence of hexadecimal digits prefixed with "0x" or "0X") and the value represented shall not exceed the limits for the corresponding type. _____________________________________________________________________________ Objection Enhancement Request Number 246 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 98) [DST-117] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove braces. 11983- 11985 should be in Roman, not italic. _____________________________________________________________________________ Page: 358 Line: 11960 Section: stdio.h Problem: See D3 ERN 195. These are NOT limits. These are macros, with exactly the same status as EOF (11977) and NULL (11979). In addition, the SEEK_* symbols can't be considered even loosely as limits. Even the text at line 11958 says they're macros. Action: Take off the braces and treat as macros. _____________________________________________________________________________ comment Enhancement Request Number 247 Clive D.W. Feather BUG in XBDd4 (rdvk# 30) [CDWF 25] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See ed recommendation (note that TMP_MAX is a limit, we have reworded the lead in to these macros) _____________________________________________________________________________ Page: 358 Line: 11975 Section: stdio.h Problem: There is no mention of the minimum limit on non-XSI systems. Action: Change the line to: The value of {TMP_MAX} is at least ~10,000 on implementations that conform to XSI~ and 25 otherwise. where ~...~ is XSI shaded and the rest is unshaded. [Ed recommendation: Accept as marked : Change the line to : The value of {TMP_MAX} is at least 25. [shadeon] On XSI-conformant systems the value of {TMP_MAX} is at least 10,000 [shadeoff] ] _____________________________________________________________________________ comment Enhancement Request Number 248 Clive D.W. Feather BUG in XBDd4 (rdvk# 31) [CDWF 26] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 359 Line: 11988 Section: stdio.h Problem: The type fpos_t must not be an array type. Action: Change "Type" to "A non-array type". [Ed recommendation: Accept as marked. As for the action above. Add to the CH. The description of the fpos_t type is now explicitly updated to exclude array types, this is for alignment with the ISO/IEC 9899:1999 standard. ] _____________________________________________________________________________ objection Enhancement Request Number 249 Clive D.W. Feather BUG in XBDd4 (rdvk# 27) [CDWF 22] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 363 Line: 12171 Section: stdlib.h Problem: The function lldiv is missing. Action: Add the line: lldiv_t lldiv (long long, long long); _____________________________________________________________________________ Comment Enhancement Request Number 250 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 80) [DST-25] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It was considered but the review group felt that this change was not needed. Add "is defined as a macro" at 12843 _____________________________________________________________________________ Page: 383 Line: 12844 Section: sys/select.h Problem: Is it reasonable to require that FD_SETSIZE be not less than OPEN_MAX? Action: Consider such a requirement. _____________________________________________________________________________ Objection Enhancement Request Number 251 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 81) [DST-26] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 389 Line: 12994 Section: sys/socket.h Problem: Shallification. Action: "maps" -> "shall map". [Ed recommendation: Accept as marked. Change "maps" to "shall map" on lines 12994 and 12996 ] _____________________________________________________________________________ Editorial Enhancement Request Number 252 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 82) [DST-27] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use "following" _____________________________________________________________________________ Page: 393 Line: 13154 Section: sys/socket.h Problem: Grammar. The use of "along" on this line is unclear. Is it intented as "along side"? If so... Action: Replace with "adjacent to" or "following". _____________________________________________________________________________ Editorial Enhancement Request Number 253 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 83) [DST-28] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 393 Line: 13156 Section: sys/socket.h Problem: Grammar. Only one pat field is actually discussed. Action: fields -> field. _____________________________________________________________________________ Objection Enhancement Request Number 254 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 99) [DST-118] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: S_IFSOCK is used for isfdtype() which is a base function. _____________________________________________________________________________ Page: 393 Line: 13226 Section: sys/stat.h Problem: Socket should be XSI shaded, too. Action: Shade it. (The text at 13217 and 13218 should be shaded as well, as it's lead-in to the XSI stuff that follows). _____________________________________________________________________________ Objection Enhancement Request Number 255 donnte@microsoft.com Bug in XBDd4 Batch 2 (rdvk# 100) [DST-119] Fri, 22 Sep 2000 15:34:51 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to future directions "No new S_IFMT symbolic names for the file type values of mode_t will be defined by this standard; if new file types are required, they will only be testable through S_ISxx() macros instead." _____________________________________________________________________________ Page: 394 Line: 13218 Section: sys/stat.h Problem: Is the purpose of this standard to try to show how to write portable applications, or is it to try to maximize the number of portable applications at the expense of all other possibilites, including growth in the number of file types (in this case)? Specifying the historical bitmask based coding of this may make a few more applications portable, but at the expense of making it rather more difficult to introduce new file types. (The macros allow hiding a lot creative alternatives that this does not.) Drop the masks completely. If there's really a need for it, provide a single macro that yields an enum (or #defined values) from st_mode, but don't make it impossible to do things like context-sensitive determination of file types. Action: Drop the shole S_IFMT stuff. This favors future growth in the marketplace, rather than constraining it artificially. ___________________________________________________________________________________ objection Enhancement Request Number 256 gwc@unisoft.com BUG in XBDd4 (preserve arithmetic types) (rdvk# 41) {gwc preserve arithmetic types} Thu, 17 Aug 2000 17:25:58 +0100 ___________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because this is a quality of implementation issue. Why make a conformance distinction based on this? The review team also believes that accepting the proposed change would decrease consensus. ___________________________________________________________________________________ Page: 406 Line: 13565 Section: sys/types.h Problem: The change in draft 4 to C99 terminology for numeric types has had a side effect whereby the "_t" types that are required to be "arithmetic" types can now be complex types. In order to preserve the previous requirements, all "_t" types that were previously required to be an "arithmetic type" should now be required to be an "integer or real floating type". In the case of regoff_t, I don't see that there is any need to allow it to be a (real) floating type. Its stated purpose is to hold the largest possible ssize_t and off_t values, and these two types are not allowed to be floating types. Action: On line 13565 change "arithmetic" to "integer or real floating". Also on page 329 line 10953 section regex.h objection change "arithmetic" to "integer". _____________________________________________________________________________ Editorial Enhancement Request Number 257 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 140) [DWC-718] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 418 Line: 13979 Section: Problem: (: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P418, L13979 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 258 Don.Cragun@eng.sun.com Bug in XBDd4 (rdvk# 141) [DWC-719] Mon, 25 Sep 2000 09:31:10 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 418 Line: 13980 Section: Problem: (: character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P418, L13980 to "". _____________________________________________________________________________ Objection Enhancement Request Number 259 donnte@microsoft.com Bug in XBDd4 Batch 1 (rdvk# 84) [DST-29] Thu, 14 Sep 2000 20:59:59 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 421 Line: 14082 Section: termios.h Problem: Actually, I like things exactly as they are, wrong though they are. This note (here, and at 14075, and using the disallowed word "must") is in a non-normative location, and thus the attempt at reserving the namespace is meaningless. Now, I don't particularly like those features to begin with (as part of a standard), so leaving it here would be perfectly fine with me. Action: None. [Ed recommendation: Accept as marked. Note that these symbols are reserved in XShd4 section 2.4, perhaps we need to refer to that in the note change lines 14074-14081 : The following names are reserved for XSI-conformant systems to use as an extension to the above, therefore strictly conforming applications shall not use them. {list as per 14076-14081} but remove XSI shading as we do not shade informative text apart from Rat shade bars delete line 14082] _____________________________________________________________________________ objection Enhancement Request Number 260 ajosey@opengroup.org Bug in XBDd4 time.h (rdvk# 4) {pasc-1003.1-84} Wed, 2 Aug 2000 12:04:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 428 Line: 14357 Section: time.h Problem: Finalised PASC Interpretation 1003.1-84 points out a defect in the namespace rules for time.h. Action: Add after line 14357: Inclusion of the header may make visible all symbols from the header. Add to Change History: IEEE PASC Interpretation 1003.1 #84 is applied adding the statement that symbols from may be made visible when is included. [Ed recommendation: Accept as marked, the added text should be CX shaded as this is an ISO C header] _____________________________________________________________________________ comment Enhancement Request Number 261 gwinn@res.ray.com Bug in XBDd4 (rdvk# 161) {JMG-1} Tue, 26 Sep 2000 01:33:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_262 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 429 Line: 14359 Section: Problem: Here and in many other places, the range of the "seconds" field is 0-61 seconds, the given reason being to handle single or double leap seconds. According to the legal definition of UTC, "ITU Reccomendation 460-4", only single positive or negative leap seconds are possible. While there may be up to four leap seconds per year, these are required to be months apart. ITU-R-TF.460-4.pdf is four pages long. If the specific words are needed, please ask. We might also wish to reference this standard as our source for the definition of UTC itself. Action: Eliminate mention of double leap seconds. Given the vast existing codebase that expects the range 0-61, leave this alone. Instead, say that the actual range is 0-60, but is left at 0-61 for historical reasons. [Ed recommendation: DUP of JMG-2, ERN 262] _____________________________________________________________________________ objection Enhancement Request Number 262 gwinn@res.ray.com Bug in XBDd4 leap seconds (rdvk# 191) {JMG-2} Tue, 26 Sep 2000 23:19:42 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to rationale "The range 0-60 seconds allows for positive or negative leap seconds. The formal definition of UTC does not permit double leap seconds, so all mention of double leap seconds has been removed, and the range shortened from the former 0-61 seconds seen in prior versions of POSIX." Also see ERN 263 _____________________________________________________________________________ Page: 429 Line: 14359 Section: Problem: This replaces JMG-1, changing a comment to an objection. JMG-1 is hereby withdrawn. Here and in many other places, the range of the "seconds" field is 0-61 seconds, the given reason being to handle single or double leap seconds. According to the legal definition of UTC, "ITU Reccomendation 460-4", only single positive or negative leap seconds are possible. While there may be up to four leap seconds per year, these are required to be months apart. ITU-R-TF.460-4.pdf is four pages long. If the specific words are needed, please ask. We might also wish to reference this standard as our source for the definition of UTC itself. Action: Eliminate mention of double leap seconds, and change the range to 0-60 seconds. This is a global change, not limited to . Change rationale by adding the following text where appropriate: "The range 0-60 seconds allows for positive or negative leap seconds. The formal definition of UTC does not permit double leap seconds, so all mention of double leap seconds has been removed, and the range shortened from the former 0-61 seconds seen in prior versions of POSIX." _____________________________________________________________________________ objection Enhancement Request Number 263 Clive D.W. Feather BUG in XBDd4 (rdvk# 32) [CDWF 27] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 429 Line: 14359 Section: time.h Problem: There is no such thing as a double leap second. Action: Change "61" to "60" and delete "or double leap second". [Ed recommendation:-accept and also change the occurrences of 00,61 to 00,60 and remove the double leap second from strftime(), strptime() and the date utility] _____________________________________________________________________________ comment Enhancement Request Number 264 Clive D.W. Feather BUG in XBDd4 (rdvk# 33) [CDWF 28] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 429 Line: 14361-14362 Section: time.h Problem: C99 does not have a sysconf function. Action: I'm not sure if this is done in these sections, but if so these two lines should be CX shaded. [Ed recommendation: REJECT. This is informative text , and does not need shading other than the present rat bars] _____________________________________________________________________________ comment Enhancement Request Number 265 Clive D.W. Feather BUG in XBDd4 (rdvk# 34) [CDWF 29] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Until we see a Technical Corrigenda from WG14 we cannot speculate on the future direction (also see Ed note). _____________________________________________________________________________ Page: 429 Line: 14366 Section: time.h Problem: SC22/WG14 (who maintain the C Standard) are looking at revamping the contents of this header to meet modern needs, so "None" is inaccurate. [Ed note: NONE is the default and infers none known] _____________________________________________________________________________ editorial Enhancement Request Number 266 Clive D.W. Feather BUG in XBDd4 (rdvk# 35) [CDWF 30] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 430 Line: 14410 Section: time.h Problem: "0.60" should be "0,60". Action: Fix. _____________________________________________________________________________ Comment Enhancement Request Number 267 Andries.Brouwer@cwi.nl BUG in XBDd4 (rdvk# 88) [] Wed, 20 Sep 2000 01:15:31 +0200 (MET DST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 440 Line: 14765 Section: _POSIX_SAVED_IDS Problem: I can parse "a, b, and c have property p, q, and r, respectively" but cannot parse "a, b, and c have property p and q, respectively". Still under _POSIX_SAVED_IDS it is written: Each process has a saved set-user-ID and a saved set-group-ID. The behavior of the setuid( ), setgid( ), and kill( ) functions shall be dependent on the values of the saved set-user-ID and the saved get-group-ID [sic], respectively. This is always set to a value greater than zero. Action: At least the typo must be corrected. Write something like: The behavior of the setuid( ) and kill( ) functions shall be dependent on the value of the saved set-user-ID. The behavior of the setgid( ) function shall be dependent on the value of the saved set-group-ID. _____________________________________________________________________________ objection Enhancement Request Number 268 Michael.Kavanaugh@oracle.com Bug in XSHd4 unistd.h (rdvk# 38) {1} Tue, 15 Aug 2000 23:45:22 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The change suggested is out of scope for this project. _____________________________________________________________________________ Page: 450 Line: 15213 Section: unistd.h Problem: Missing _SC_NPROCESSORS_ONLN as per current use in Sun Solaris, IBM AIX, and Compaq Tru64. This will be the only portable way to determine the number of active processors on a system, required for application latching and process operations. . Also needed @ page 1980 line 45539 section sysconf Action: Here and also at page 1980 line 45539 section sysconf objection Add "_SC_NPROCESSORS_ONLN" into list of symbolic constants. _____________________________________________________________________________ objection Enhancement Request Number 269 Clive D.W. Feather BUG in XBDd4 (rdvk# 36) [CDWF 31] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: make these XSI extensions page 462 line 15697-15698: change to XSI wctype_t As described in page 462 line 15718-15729: iswalnum to iswxdigit - XSI shade these lines page 463 line 15742-15743: towlower and towupper - XSI shade these lines page 464 line 15786: wctype Add to the CH: The type wctype_t, the isw*(), to*() and wctype() functions are marked as XSI extensions. _____________________________________________________________________________ Page: 462 Line: 15697-15698 Section: wchar.h Problem: Many of the symbols listed here are defined in wctype.h, not wchar.h, in the C Standard. They should be deleted. Action: Delete the following symbols: page 462 line 15697-15698: wctype_t page 462 line 15718-15729: iswalnum to iswxdigit page 463 line 15742-15743: towlower and towupper page 464 line 15786: wctype If it desired to have these symbols visible, add to the list on line 15804. _____________________________________________________________________________ objection Enhancement Request Number 270 Clive D.W. Feather BUG in XBDd4 (rdvk# 13) [CDWF 8] Fri, 11 Aug 2000 11:24:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 464 Line: 15803-15804 Section: wchar.h Problem: C99 states that no header includes another (with one exception). Therefore any text suggesting the opposite should be CX shaded. Action: CX shade these two lines and page 466 line 15876-15877 section wctype.h. Also CX shade the new text included as part of the Andrew Josey comments tagged {pasc-1003.1-84} and {pasc-1003.1-85} (page 323 line 11450 and page 428 line 14357). [Ed recommendation: Accept as marked, part of the second part is already covered in the Ed recommendations to rdvk #3,4 (note rdvk seq, not ERN seq). Note that it does not apply to pthread.h since that is not an ISO C header, the ISO C reqt only applies to ISO headers, or at worst only needs to be flagged as a CX on headers that are ISO C headers] _________________________________________________________________________________________________ objection Enhancement Request Number 271 Bruce Barrow a.josey 15480) BUG in XBDd4 (rdvk# 241) [b.barrow@ieee.org_1003.1comment1_ieee_SCC14coordination] Wed, 27 Sep 2000 16:08:37 -0400 _________________________________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (actually a bug in XCU) The term kilobytes will be removed where it is used The term megabyte is only used in rationale change ps command so as to use units of 1024 bytes (as in 1003.2). Also mailx use 100_000 bytes in app usage, page 2814, line 23183. (also checked megabyte usage, all is OK). _________________________________________________________________________________________________ Page: 2963 Line: 29126 Section: vsz Problem: (vsz) This specification defines "The size of the process in (virtual) memory in kilobytes as a decimal integer." The term kilobyte is not defined in this standard, and two definitions are in common use. Microsoft, for example, defines a kilobyte as 1024 bytes. Major international and IEEE standards, however, deprecate this usage and define the kilobyte as 1000 bytes. (See, for example, "Le Systeme international d'unites," BIPM, 1998, p. 103; IEEE/ASTM SI 10-1997.) If it is important for 1003.1 to have a unit of 1024 bytes, the term kibibyte should be used. This has been standardized internationally in Amendment 2 to IEC 60027-2, 1999. Action: Add: "kilobyte 1000 bytes megabyte 1 000 000 bytes" in Clause 3, Definitions. _____________________________________________________________________________ editorial Enhancement Request Number 272 pete.forman@westgeo.com Bug in XBDd4 13. Headers (rdvk# 86) {PWF20000919/3} Tue, 19 Sep 2000 11:50:03 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove from unistd.h Delete line 15323. Delete line 15378. Add to CH the brk() and sbrk() legacy functions are removed _____________________________________________________________________________ Page: 4522 Line: 15323 Section: 13. Problem: The legacy interfaces brk() and sbrk() have been removed from XSHd4. This is noted in 1.1 Scope, p 2, lines 62 - 66. References in this header should be removed, namely the declarations and entries under "SEE ALSO". The historical references on p. 457 should remain. In XSHd4 p 519 (The Compilation Environment) the identifiers "brk" and "sbrk" are reserved. I consider that they ahould be removed from the list but this might be debated. I have not raised a bug action to do that. In XRATd4 B.2.8 p 3423 brk() and sbrk() are referenced. This is of little consequence. Perhaps an extra qualifier "obsolete" might be inserted. I have not raised a bug action to do that. Action: Delete line 15323. Delete line 15378. Delete the string "brk(), " from line 15546. Delete the string "sbrk(), " from line 15547.