Document Number: AUSTIN/74r2 Title: XBDd5 Aardvark Change Request Report (FINAL) Revision Date: 2001-04-09 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XBD Draft 5. Aardvark Summary Table (XBDd5) ______________________ ERN 1 Accept ERN 2 Accept ERN 3 Reject ERN 4 Reject ERN 5 Accept ERN 6 Duplicate of 2 ERN 7 Accept ERN 8 Duplicate of 5 ERN 9 Accept ERN 10 Accept as marked ERN 11 Accept as marked ERN 12 Accept as marked ERN 13 Reject ERN 14 Accept ERN 15 Accept as marked ERN 16 Accept ERN 17 Accept ERN 18 Accept ERN 19 Duplicate of 20 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 as marked ERN 27 Accept as marked ERN 28 Accept 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 as marked ERN 35 Accept as marked ERN 36 Accept as marked ERN 37 Accept as marked ERN 38 Accept as marked ERN 39 Accept ERN 40 Duplicate of 52 ERN 41 Accept ERN 42 Accept ERN 43 Accept ERN 44 Accept ERN 45 Accept ERN 46 Accept ERN 47 Accept ERN 48 Accept ERN 49 Accept ERN 50 Duplicate of 52 ERN 51 Accept ERN 52 Accept ERN 53 Accept ERN 54 Accept ERN 55 Accept ERN 56 Accept ERN 57 Accept as marked ERN 58 Reject ERN 59 Reject ERN 60 Accept ERN 61 Accept as marked ERN 62 Accept as marked ERN 63 Accept ERN 64 Accept ERN 65 Accept ERN 66 Accept as marked ERN 67 Accept as marked ERN 68 Accept ERN 69 Accept ERN 70 Accept as marked ERN 71 Accept ERN 72 Accept as marked ERN 73 Accept as marked ERN 74 Duplicate of 76 ERN 75 Reject ERN 76 Accept as marked ERN 77 Accept ERN 78 Accept ERN 79 Accept ERN 80 Accept ERN 81 Accept ERN 82 Accept ERN 83 Accept ERN 84 Accept ERN 85 Accept ERN 86 Accept ERN 87 Accept ERN 88 Accept ERN 89 Accept ERN 90 Accept ERN 91 Accept ERN 92 Accept ERN 93 Accept ERN 94 Accept ERN 95 Accept ERN 96 Accept ERN 97 Accept ERN 98 Reject 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 ERN 111 Accept ERN 112 Accept ERN 113 Accept ERN 114 Accept ERN 115 Accept ERN 116 Accept ERN 117 Accept ERN 118 Accept ERN 119 Accept ERN 120 Accept ERN 121 Accept as marked ERN 122 Accept ERN 123 Accept ERN 124 Accept ERN 125 Accept ERN 126 Accept ERN 127 Accept ERN 128 Accept ERN 129 Accept ERN 130 Accept ERN 131 Accept ERN 132 Accept ERN 133 Accept ERN 134 Accept ERN 135 Accept as marked ERN 136 Accept as marked ERN 137 Reject ERN 138 Reject ERN 139 Reject ERN 140 Accept ERN 141 Accept ERN 142 Accept ERN 143 Accept ERN 144 Accept ERN 145 Accept ERN 146 Accept ERN 147 Accept ERN 148 Reject ERN 149 Accept ERN 150 Accept ERN 151 Accept ERN 152 Accept as marked ERN 153 Accept ERN 154 Accept ERN 155 Accept ERN 156 Accept ERN 157 Accept ERN 158 Accept ERN 159 Accept ERN 160 Accept ERN 161 Reject ERN 162 Accept ERN 163 Accept as marked ERN 164 Reject ERN 165 Duplicate of 139 ERN 166 Duplicate of 139 ERN 167 Accept ERN 168 Accept ERN 169 Accept ERN 170 Accept ERN 171 Accept ERN 172 Accept ERN 173 Accept ERN 174 Accept ERN 175 Accept ERN 176 Accept ERN 177 Accept ERN 178 Accept ERN 179 Accept as marked ERN 180 Accept ERN 181 Accept ERN 182 Accept ERN 183 Accept ERN 184 Accept ERN 185 Accept ERN 186 Accept ERN 187 Accept ERN 188 Accept ERN 189 Accept ERN 190 Accept ERN 191 Accept ERN 192 Accept as marked ERN 193 Reject ERN 194 Duplicate of 192 ERN 195 Accept ERN 196 Reject ERN 197 Accept ERN 198 Accept ERN 199 Reject ERN 200 Reject ERN 201 Accept ERN 202 Accept as marked ERN 203 Accept ERN 204 Accept ERN 205 Accept ERN 206 Accept ERN 207 Accept ERN 208 Accept ERN 209 Reject ERN 210 Reject ERN 211 Accept ERN 212 Accept ERN 213 Accept ERN 214 Accept ERN 215 Accept ERN 216 Accept as marked ERN 217 Reject ERN 218 Accept as marked ERN 219 Reject ERN 220 Accept ERN 221 Accept as marked ERN 222 Accept ERN 223 Accept as marked ERN 224 Accept as marked ERN 225 Accept as marked ERN 226 Duplicate of 148 ERN 227 Accept as marked ERN 228 Reject ERN 229 Accept ERN 230 Accept ERN 231 Accept ERN 232 Accept ERN 233 Accept ERN 234 Accept ERN 235 Accept ERN 236 Accept ERN 237 Accept ERN 238 Accept ERN 239 Accept ERN 240 Accept ERN 241 Accept ERN 242 Accept ERN 243 Accept ERN 244 Accept ERN 245 Accept ERN 246 Accept ERN 247 Accept ERN 248 Accept ERN 249 Accept ERN 250 Accept ERN 251 Accept ERN 252 Accept ERN 253 Accept ERN 254 Accept ERN 255 Accept ERN 256 Accept ERN 257 Accept ERN 258 Accept ERN 259 Accept ERN 260 Accept ERN 261 Accept ERN 262 Accept ERN 263 Accept ERN 264 Accept ERN 265 Accept ERN 266 Accept ERN 267 Accept ERN 268 Accept ERN 269 Accept ERN 270 Accept ERN 271 Accept ERN 272 Accept ERN 273 Accept ERN 274 Accept ERN 275 Accept ERN 276 Accept ERN 277 Accept ERN 278 Accept ERN 279 Accept ERN 280 Accept ERN 281 Accept ERN 282 Accept ERN 283 Accept ERN 284 Accept ERN 285 Accept ERN 286 Accept ERN 287 Accept ERN 288 Accept ERN 289 Accept ERN 290 Accept ERN 291 Reject ERN 292 Reject ERN 293 Reject ERN 294 Accept ERN 295 Accept ERN 296 Accept ERN 297 Reject ERN 298 Reject ERN 299 Accept ERN 300 Accept ERN 301 Accept ERN 302 Accept ERN 303 Accept as marked ERN 304 Accept ERN 305 Reject ERN 306 Accept ERN 307 Accept ERN 308 Accept as marked ERN 309 Reject ERN 310 Accept ERN 311 Accept ERN 312 Accept ERN 313 Reject ERN 314 Accept ERN 315 Accept ERN 316 Accept as marked ERN 317 Accept ERN 318 Duplicate of 322 ERN 319 Duplicate of 322 ERN 320 Duplicate of 322 ERN 321 Duplicate of 322 ERN 322 Accept as marked ERN 323 Duplicate of 322 ERN 324 Accept as marked ERN 325 Accept ERN 326 Accept ERN 327 Reject ERN 328 Accept ERN 329 Accept ERN 330 Accept ERN 331 Accept ERN 332 Reject ERN 333 Accept ERN 334 Accept as marked ERN 335 Accept ERN 336 Accept ERN 337 Accept as marked ERN 338 Reject ERN 339 Reject ERN 340 Accept ERN 341 Accept ERN 342 Accept ERN 343 Accept ERN 344 Accept ERN 345 Reject ERN 346 Accept ERN 347 Accept as marked ERN 348 Duplicate of 349 ERN 349 Accept ERN 350 Accept ERN 351 Accept as marked ERN 352 Accept ERN 353 Accept ERN 354 Accept ERN 355 Accept ERN 356 Duplicate of 4 ERN 357 Accept ERN 358 Accept ERN 359 Accept ERN 360 Accept ERN 361 Accept ERN 362 Accept ERN 363 Accept as marked ERN 364 Accept as marked ERN 365 Accept as marked ERN 366 Reject ERN 367 Reject ERN 368 Accept ERN 369 Accept as marked ERN 370 Accept ERN 371 Accept as marked ERN 372 Reject ERN 373 Duplicate of 374 ERN 374 Accept ERN 375 Accept ERN 376 Accept ERN 377 Accept as marked ERN 378 Accept as marked ERN 379 Reject ERN 380 Accept as marked ERN 381 Accept ERN 382 Accept ERN 383 Accept as marked ERN 384 Accept as marked ERN 385 Accept as marked ERN 386 Accept ERN 387 Accept ERN 388 Accept ERN 389 Accept ERN 390 Accept ERN 391 Accept ERN 392 Accept ERN 393 Accept as marked _____________________________________________________________________________ COMMENT Enhancement Request Number 1 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 333) [roger.martin@sun.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I agree with the comments that Don Cragun is submitting with his ballot and recommend that those comments be addressed. Action: [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 2 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 331) [don.cragun@eng.sun.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have submitted several comments and editorial comments directly to the Austin Group alias for this ballot. Action: Make the changes suggested in the comments I have submitted to the Austin Group alias. _____________________________________________________________________________ COMMENT Enhancement Request Number 3 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 330) [Robert.Barned@lmco.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Add a specification of how a raw socket is used to update routing tables Action: Add the requested specification to the appropriate interfaces [Ed recommendation: Reject Routing tables are outside the scope of the revision. It is also unclear whether a raw socket would be used to do this. As such we have to reject this item. As background information, the current definition of raw sockets is as far as we could get and retain concensus. ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 329) [j.isaak@computer.org] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Although some of the group agreed that in principle it is not an unreasonable thing to do, the group could not find a place to bring it in scope. First - the review group did not feel that creating a new requirement where the interpretation stated that there was no requirement, is in scope. Second - the review group did not feel that Interpretation 1003.1 #60 brought this into scope - it was not tagged in the IEEE interpretations process as a defect, and the currently approved standard does not make a requirement in this area either. Thirdly this was not a requirement in the NIST FIPS 151-2. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: The response to my objection relating to the range of UID's required by the standard is incorrect. First - what I have requested is the establishing of a minimum value allowed for the uid_t in sys/types.h and assurance that conforming systems can set this value. This is within scope, and must be treated as an objection within scope. Second - this is directly tied to an early request for interpretation of the standard, from NIST, related to the range of UID values that must be permitted, and a defined way to set these values in POSIX conformance testing. As such it is not a new 'problem' but on of the first raised with respect to 1003.1 Beyond the testing/conformance issue, I have subsequently talked with entities (government agencies and universities) who wanted to have unique UID's established for very large numbers of users (often across a number of conforming systems) which is the incentive for pushing this value higher than one of the traditional values of 16K .... although as indicated in my objection, 16K would be acceptable in repsonse to my objection. (I realize that any signficant change from the installed base of major UNIX vendors would raise concerns by members of The Open Group, so I've tried to focus my request in a space where most, if not all Open Group members would find 'no change' in their existing documentation or implementations.) I belive that the appropriate profiling is not to include this in a profile, but make this a primary requirement. Then an embedded system profile could take exception in cases where that might be needed (I suspect secure embedded systems would also find value in a reasonably large range of UID's -- at least enough to keep a 16 bit value for storing these.) Action: The simple remedy is to accept the objection, and indicate a minimum range of UID values. An alternate remedy is to provide a response to the objection which does not try to deny the objection being in scope. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 328) [prindle@ieee.org] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ 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. _____________________________________________________________________________ COMMENT Enhancement Request Number 6 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 325) [don.cragun@eng.sun.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_2 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: I have submitted several comments and editorial comments directly to the Austin Group alias for this ballot. Action: Make the changes suggested in the comments I have submitted to the Austin Group alias. _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 115) [DST-91] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: all Line: all Section: all Problem: I have found and marked a goodly number of problems with misuse of verbs or "shall", and indicated corrections to them. However, I am quite sure that many more remain, many of them very likely as elements of repeating patterns where I did not find all instances of the pattern. Action: Editor to look for overlooked pattern elements after correcting what is here and correct similarly. (It's a lot easier in the document source than via aardvarks.) [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 324) [prindle@ieee.org] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_5 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: all Line: all Section: all 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 9 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 327) [donnte@microsoft.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: all Line: all Section: all Problem: I have submitted slightly over 2000 comments and objections via the Austin Group submission process, and support them here. Half or more of those objections/comments deal with the proper use of "shall" (or imperative mode) in general. The fact that I was able to find this many, indicates that probably many more such problems remain undiscovered. Action: As suggested there. Carefully vet the next draft for proper use of shall prior to circulation. [Ed recommendation: Accept] [We thank Donn for his thorough efforts here. Many of the changes identified are strengthenings of the original wording from the base document and we thank Donn for this detailed work.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 Joseph S. Myers BUG in XBDd5 (rdvk# 51) [JSM-6] Sat, 13 Jan 2001 18:45:09 +0000 (GMT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 1 Line: 1 Section: binding Problem: The existing POSIX standards are excessively expensive ($143 for 9945-1:1996 of 784 pages; $271 for 9945-2:1993 of 1328 pages, according to http://standards.ieee.org/catalog/posix.html, for non-IEEE members). Extrapolating to the present draft of 3682 pages suggests a price for the final standard of around 700 US dollars. Such a price serves as a strong discouragement to buying the standard for anyone who does Unix programming but is neither a standards geek nor sufficiently serious about their Unix programming to spend $700 on the standard. Furthermore, the paperback bindings of the current standards are not sufficiently robust to stand up to several years of heavy use; pages come loose and some volumes are sufficiently thick and heavy that the spines crease under the weight of the opened volume. This should not be allowed to happen for the new edition; it should have higher production quality and lower price. By way of comparison, the Unicode Standard version 3.0, published by Addison-Wesley, hardcover, 1072 pages, sells at $50. It should be possible for a version of the revised POSIX standard, in a robust hardcover binding, to sell at $200. This Aardvark is intended as an entirely serious point about how to make the standard more or less useful, even if the bindings, covers and proposed price are not included in the PDFs of this draft. I'm rather expecting an out-of-scope rejection, but please justify any such rejection with reference to where the scope rules out discussion of the physical form and cost of the standard and to the appropriate channels for making representations such as this. Action: Ensure that the printed standard meets the following criteria: 1) The physical form, including bindings, covers and all internal text and figures, is completely identical in all printed copies of the standard distributed by ISO, IEC, IEEE or the Open Group. The situation of ISO/IEC 9945-2:1993 (joint IEEE/ISO/IEC version) page xi footnote 3 (lines 60-67) should be avoided for this standard, and there should be no question of buying from a different provider of the standard providing a better or worse or different product than from any other. 2) The physical form is hardcover, sewn bindings, acid-free and durable (say under at least ten years' heavy use). 3) The price is not much over 200 US dollars, or equivalent in the currency of the distributing standards body (GBP/CHF). 4) Some effort is made to encourage bookshops to stock the standard for sale on their shelves. (This means, for example, providing such discounts to bookshops as may be conventional, to make it economic for them to handle the standard, notwithstanding present IEEE/ISO/IEC policy to the contrary.) If the price is to be anywhere near 700 dollars, that is plainly an absurdly high price even if some of the price is justified by, for example, gilded edges to the pages, slip-cases, and permanent rag-based paper meeting standards for permanence such as ISO 9706:1994. If a PDF form of the standard is sold, such restrictive terms as have lately been applied to the PDF form of ISO/IEC 9899:1999 should not be applied to it; it should be ensured that the licence terms do not restrict it further than (a) limiting it to one simultaneous user and (b) advising that the printed standard is authoritative; no technical protection measures should be used to enforce this, the file should not be password-protected and copying text from it should be technically allowed, and the file should have a single widely publicised checksum (MD5 / SHA-1 / ...) to avoid attempts at watermarking. -- Joseph S. Myers jsm28@cam.ac.uk [Ed recommendation: Accept as marked This has been downgraded to a comment since no textual changes were supplied to the document. It is also inappropriate for an item to discuss pricing, and for that reason this was also not considered or addressed by the review group. The item has been passed to the IEEE for information] _____________________________________________________________________________ COMMENT Enhancement Request Number 11 donnte@microsoft.com Bug in xbdd5 (rdvk# 46) [DST-87] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We could do this if we have some global items we can check in first, and then checkout the sources again. Agreed to do this for "path name"->"pathname", "file name"->"filename" and a small number of other global editorials. This will be flagged in the reviewers notes. _____________________________________________________________________________ Page: 1 Line: 1 Section: all Problem: Is there any chance that in the next draft, revision bars which mark the name of the standard could be omitted. In the last 2 (3?) drafts, they seem to all have been marked, and it makes it markedly difficult to identify (particularly nearby) changes that are really significant. Action: Don't apply revision bars to the name of the standard. Consider flagging certain other mechanical, mindless changes (where technically feasable) in the reviewer's notes once, rather than at every point of change. (The newline -> change comes to mind, even tho it did lead me to spotting a few other things.) [Ed recommendation: None This is not possible for us to do, it has to be automatic due to the size of the document] _____________________________________________________________________________ COMMENT Enhancement Request Number 12 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 305) [DST-1997] Tue, 6 Feb 2001 22:07:05 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the new text suggested in the action below (applies to 782-786 only) Keep 796-803 after new text, remove 794-795 _____________________________________________________________________________ Page: xxi Line: 782 Section: intro Problem: "There are no known..." really no longer makes sense. "There *were* know known..." does, but then C99 confuses things, because the C99 changes make the original statement technically true, but in a different spirit. Action: I think this meets the spirit of it: When the original version of this standard was published, there were no known historical implementations that did not have to change. However, there was a broad consensus on a set of functions, types, definitions and concepts that formed an interface that was common to most historical implementations. The adoption of the 1988 and 1990 IEEE interface standards, the 1992 commands standard, the various TOG (formerly X/Open) versions, and the subsequent revisions and addenda to all of them have consolidated this consensus, and this revision reflects the significantly increased level of consensus arrived at since the original versions. The earlier standards and their modifications specified a number of areas where consensus had not been reached before, and these now are now reflected in this revision. The authors of the original versions tried, as much as possible to follow the principles below when creating new specifications: [787-793] This revision tries to minimize the number of changes required to implementations which conform to the earlier versions of the approved standards to bring them into conformance with the current standard. Specifically, the scope of this work excluded doing any "new" work, but rather collecting into a single document what had been spread across a nubmer of documents, and presenting it in what had been proven in practice to be a more effective way. Some changes to prior conforming implementations were unavoidable, primarily as a consequence of resolving conflicts found in prior revisions, or which became apparent when bringing the various pieces together. However, since it references the 1999 version of the C standard, and no longer supports "common usage" C there are a number of unavoidable changes. Application portability is similarly affected. _____________________________________________________________________________ COMMENT Enhancement Request Number 13 donnte@microsoft.com Bug in xbdd5 (rdvk# 17) [DST-1] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: xxvii Line: 948 Section: Referenced Problem: I don't believe that all the references below are actually referenced in the document. Action: -> "The following documents are referenced non-normatively in or may prove useful in understanding the context of the document." [Ed recommendation: Reject These were checked for this draft and will be checked again for the next draft. Everything listed is mentioned in normative text. ] _____________________________________________________________________________ COMMENT Enhancement Request Number 14 donnte@microsoft.com Bug in xbdd5 (rdvk# 18) [DST-2] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (note to ed: also see XBD ERN 15) _____________________________________________________________________________ Page: 3 Line: 110 Section: Introduction Problem: OH, OF and UN are at this point undefined, and it's hard to get the intent of the standard (reading this section first) with those terms still undefined. Action: "OH" -> "OH (optional headers)", "OF" -> "OF (Output format incompletely specified)", "UN" -> "UN (possibly unsupportable)" _____________________________________________________________________________ COMMENT Enhancement Request Number 15 donnte@microsoft.com Bug in xbdd5 (rdvk# 19) [DST-3] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove UN shading option and marking and associated text on XBDd5 p 13 Remove UN margin markings and UN shading (note that the text that is shaded stays) for uucp uustat uux also for XRAT p3303 On the uccp, uustat and uux manual pages add CH The UN margin markings and associated shading are removed as per The Open Group Base Working Group resolution bwg2001-003 _____________________________________________________________________________ Page: 13 Line: 549 Section: Introduction Problem: The description of UN is a bit hard to follow without something real to hang your hat on that is marked UN. Uucp is the only extant feature with a UN notation (and a good way to get rid of the UN notation would be to get rid of uucp :-) ). Action: Add, "Note, an example of this is uucp." _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 prindle@ieee.org (rdvk# 84) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 18 Line: 660-675 Section: 2.1.3.1 [prindle.xbd-30] Problem: Two profiling option groups need to be added to this list, one that should have always been there, and one added by [prindle.xbd-29]. Action: Add in proper alphabetical order: - _POSIX_FILE_LOCKING - _POSIX_C_LIB_EXT [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 prindle@ieee.org (rdvk# 314) [prindle.xbd-33] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 18 Line: 667 Section: 2.1.3.1 Problem: New profiling option group added by [prindle.xbd-32] needs to be added to this list. Action: Add before line 667: - _POSIX_FILE_SYSTEM_EXT [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 prindle@ieee.org (rdvk# 85) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 19 Line: 683 Section: 2.1.3.1 [prindle.xbd-31] Problem: The XSI profiling option groups added by [prindle.xbd-28] need to be added to this list. Action: Before this line, add: - _XSI_C_LANG_SUPPORT - _XSI_DBM - _XSI_DEVICE_IO - _XSI_DEVICE_SPECIFIC - _XSI_DYNAMIC_LINKING - _XSI_FD_MGMT - _XSI_FILE_SYSTEM - _XSI_I18N - _XSI_IPC - _XSI_JOB_CONTROL - _XSI_MULTI_PROCESS - _XSI_SIGNALS - _XSI_SINGLE_PROCESS - _XSI_SYSTEM_DATABASE - _XSI_SYSTEM_LOGGING - _XSI_THREAD_MUTEX_EXT - _XSI_THREADS_EXT - _XSI_TIMERS - _XSI_USER_GROUPS [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 19 prindle@ieee.org (rdvk# 320) [prindle.xbd-39] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_20 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 23-26 Line: 841-976 Section: 2.1.5.1 Problem: This entire section on profiling options clutters this front matter with requirements that are only of significance to writers, implementors, and users of POSIX standard profiles. Therefore, it should be moved to a normative annex that reflects that these profiling options cannot be specified by implementations wishing to conform to this standard, but only by implementations wishing to conform to a POSIX standard profile that itself selects among these profiling options. Action: Move this section to a normative annex. [Ed recommendation: DUP of the next one ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 ajosey@opengroup.org Bug in XBDd5 2.1.5.1 (rdvk# 339) {aj.feb13.1} Tue, 13 Feb 2001 13:55:59 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 23 Line: 841 Section: 2.1.5.1 Problem: This section describes profiling options for systems which subset the main 1003.1-200x standard. As such the section would be better placed into a separate normative chapter. This will reduce the clutter in the front matter and make the conformance requirements clearer. This change is in scope as per the Austin 9r6 document. Action: Move section 2.1.5.1 to a separate chapter of XBD. This is a normative chapter. The chapter should be titled: "Subprofiling Option Groups" Add a footnote to "The following Option Groups" (was on p23 line 842) "These are equivalent to the Units of Functionality from IEEE Std 1003.13-1998." Add a new second sentence after sentence one on line 842. "Systems claiming support to IEEE Std 1003.1-200x need not implement these options apart from the requirements stated in section 2.1.3 POSIX conformance." Change reference on p18 l 659 to point to the new chapter After moving clause 2.1.5.1 , Add a new end paragraph in clause 2.1.5 "Option Groups for subprofiling, that is supporting smaller profiles of functionality based on IEEE Std 1003.1-200x, are described in chapter XXX Subprofiling Option Groups. Profile standards based on IEEE Std 1003.1-200x shall not further subset the Option Groups." [Ed recommendation: Accept] [Ed note, at the meeting the consensus was to move this to an informative annex and to rework the frontmatter. A separate chapter was circulated and implemented in D6] _____________________________________________________________________________ COMMENT Enhancement Request Number 21 prindle@ieee.org (rdvk# 321) [prindle.xbd-40] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 23-24 Line: 845-890 Section: 2.1.5.1 Problem: There has been strong sentiment from Andrew, Don, and Dave Emery that the ISO C library should be partitioned such that the pure math functions, the wide character manipulation functions (e.g. wcsspn()), the wide character I/O functions (e.g. fputwc()), and the pairs of functions be partitioned out into separate profiling option groups (i.e. separate from the existing _POSIX_C_LANG_SUPPORT and the proposed _XSI_C_LANG_SUPPORT). I'm concerned that this will create a situation similar to the subsetting of .1 by .13 several years back. That is, the ISO C library is part-and-parcel with the ISO C compiler. One can't claim conformance to the ISO C standard without providing both the compiler for the language, and the standard library in its entirety (I don't recall options along these lines in ISO C 99). So if we introduce profiling options here, might the ISO C community be up-in-arms over the implied subsetting that POSIX standard profiles can then accomplish? The argument for this partitioning is that small programmable handheld devices could be built more economically if not required to carry library code that is not likely to be used; such library code also would not need to be developed or maintained by vendors of such devices. The other side of the argument is that the pervailing international market for any such devices begs the wisdom of leaving out the wc functionality, and math functions are basic and often taken for granted. Plus, with 64MB of tiny flash memory going for under $100 retail, considerably less to OEMs, it is difficult to fully justify such partitioning strictly based on the bloat factor. Nevertheless, I offer the option here if the majority feel it's a worthwhile split. Action: Here are the changes required to accomplish this. In the specified section (or in the new annex if [prindle.xbd-39] is accepted): Remove all math functions from group _POSIX_C_LANG_SUPPORT and place into a new group _POSIX_C_LANG_MATH. These functions are precisely the non-XSI functions prototyped in . Remove all math functions from proposed group _XSI_C_LANG_SUPPORT and place into a new group _XSI_MATH. These functions are precisely the XSI functions prototyped in . Remove all wide character manipulation functions (those which do not do I/O) from _POSIX_C_LANG_SUPPORT and place into a new group _POSIX_C_LANG_WIDE_CHAR. These functions are precisely the functions prototyped in except for those listed below to go into _POSIX_WIDE_CHAR_DEVICE_IO and except for the 3 XSI functions wcswcs(), wcswidth(), wcwidth(). Remove all wide character manipulation functions from proposed group _XSI_C_LANG_SUPPORT and place into a new group _XSI_WIDE_CHAR. These functions are precisely wcswcs(), wcswidth(), and wcwidth(). Remove all wide character I/O functions from _POSIX_DEVICE_IO and place into a new group _POSIX_WIDE_CHAR_DEVICE_IO. These functions are (please check this list): fgetwc() fgetws() fputws() fwprintf() fwscanf() getwc() getwchar() putwc() putwchar() ungetwc() vfwprintf() vfwscanf() vwprintf() vwscanf() wprintf() wscanf() Remove setjmp() and longjmp() from _POSIX_C_LANG_SUPPORT and place into a new group _POSIX_C_LANG_JUMP. Remove _setjmp() and _longjmp() from proposed group _XSI_C_LANG_SUPPORT and place in new group _XSI_JUMP. Remove sigsetjmp() and siglongjmp() from group _POSIX_SIGNALS and place into new group _POSIX_SIGNAL_JUMP. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 prindle@ieee.org (rdvk# 55) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 23 Line: 859 Section: 2.1.5.1 [prindle.xbd-1] Problem: No functions named fegetwc() and fegetws() exist. Action: Remove those two function names from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 prindle@ieee.org (rdvk# 56) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 23 Line: 861-862 Section: 2.1.5.1 [prindle.xbd-2] Problem: The functions named fwide(), fwprintf(), fwrite(), fwscanf(), getwc(), and getwchar() do not belong in this profiling option group, but rather in the _POSIX_DEVICE_IO profiling option group. Action: Remove those 6 function names from this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 prindle@ieee.org (rdvk# 57) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 875 Section: 2.1.5.1 [prindle.xbd-3] Problem: The functions named putwc() and putwchar() do not belong in this profiling option group, but rather in the _POSIX_DEVICE_IO profiling option group. Action: Remove those 2 function names from this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 prindle@ieee.org (rdvk# 62) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 878 Section: 2.1.5.1 [prindle.xbd-8] Problem: The function named wctype() is missing from this profiling option group (does not currently appear in any profiling option group). Action: Add before wmemchr() the function name "wctype()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 prindle@ieee.org (rdvk# 61) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 878 Section: 2.1.5.1 [prindle.xbd-7] Problem: The function named snprintf() belongs in this profiling option group instead of in the _POSIX_DEVICE_IO profiling option group. Action: Add before sprintf() the function name "snprintf()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 prindle@ieee.org (rdvk# 59) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 884 Section: 2.1.5.1 [prindle.xbd-5] Problem: The functions named vfwprintf() and vfwscanf() do not belong in this profiling option group, but rather in the _POSIX_DEVICE_IO profiling option group. Action: Remove those 2 function names from this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 prindle@ieee.org (rdvk# 58) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 24 Line: 884 Section: 2.1.5.1 [prindle.xbd-4] Problem: The function named tzname() does not exist. Instead, the proper interface is the externally defined name tzname. Action: Remove the parentheses "()" from "tzname()" and leave just "tzname". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 29 prindle@ieee.org (rdvk# 60) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 885 Section: 2.1.5.1 [prindle.xbd-6] Problem: The functions named vwprintf() and vwscanf() do not belong in this profiling option group, but rather in the _POSIX_DEVICE_IO profiling option group. Action: Remove those 2 function names from this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 prindle@ieee.org (rdvk# 83) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 893 Section: 2.1.5.1 [prindle.xbd-29] Problem: Not every interface name in this standard belongs to either an option group or a profiling option group. Many such functions nonetheless need not be required in implementations supporting certain standard realtime (or other) profiles. To assist the profiling projects, new profiling option groups need to be created for POSIX functionality that is not otherwise optional. In particular, the following interfaces provide extended string parsing, searching, and manipulation much in the spirit of the string.h functions. Although they are often associated with utilities, they are by no means limited to use by the POSIX utilities, nor do they require kernel services (i.e. they provide OS independent functionality similar to qsort() or strtok()). Action: Add before this line the following additional profiling option group: _POSIX_C_LIB_EXT General C Library Extension fnmatch() getopt() optarg opterr optind optopt regcomp() regerror() regexec() regfree() [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 prindle@ieee.org (rdvk# 63) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 895 Section: 2.1.5.1 [prindle.xbd-9] Problem: The functions named fgetwc() and fgetws() are missing from this profiling option group (do not currently appear in any profiling option group). Action: Add before fileno() the function names "fgetwc()" and "fgetws()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 prindle@ieee.org (rdvk# 64) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 896 Section: 2.1.5.1 [prindle.xbd-10] Problem: The functions named fwide(), fwprintf(), fwrite(), and fwscanf() belong in this profiling option group instead of in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Add before getc() the function names "fwide()", "fwprintf()", "fwrite()", and "fwscanf()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 prindle@ieee.org (rdvk# 66) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 896 Section: 2.1.5.1 [prindle.xbd-12] Problem: The functions named putwc() and putwchar() belong in this profiling option group instead of in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Add before read() the function names "putwc()" and "putwchar()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 prindle@ieee.org (rdvk# 65) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 896 Section: 2.1.5.1 [prindle.xbd-11] Problem: The functions named getwc() and getwchar() belong in this profiling option group instead of in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Add before open() the function names "getwc()" and "getwchar()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 prindle@ieee.org (rdvk# 67) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 897 Section: 2.1.5.1 [prindle.xbd-13] Problem: The function named snprintf() does not belong in this profiling option group, but rather in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Remove this function name from this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 prindle@ieee.org (rdvk# 68) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 897 Section: 2.1.5.1 [prindle.xbd-14] Problem: The functions named stderr(), stdin(), stdout() do not exist. Instead, the proper interfaces are the externally defined names stderr, stdin, stdout. Action: Remove the parentheses "()" from "stderr()", "stdin()", "stdout()" and leave just "stderr", "stdin", and "stdout". [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 prindle@ieee.org (rdvk# 69) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 898 Section: 2.1.5.1 [prindle.xbd-15] Problem: The functions named vfwprintf() and vfwscanf() belong in this profiling option group instead of in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Add before vprintf() the function names "vfwprintf()" and "vfwscanf()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 38 prindle@ieee.org (rdvk# 70) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 898 Section: 2.1.5.1 [prindle.xbd-16] Problem: The functions named vwprintf() and vwscanf() belong in this profiling option group instead of in the _POSIX_C_LANG_SUPPORT profiling option group. Action: Add before wprintf() the function names "vwprintf()" and "vwscanf()" to this list. [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 prindle@ieee.org (rdvk# 315) [prindle.xbd-34] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 24 Line: 915-917 Section: 2.1.5.1 Problem: The functions lstat(), readlink(), and symlink() should be further broken out into a profiling option group that not only reflects the need for a file system, but support for symbolic links within that file system, a capability that a simple file system in an embedded controller, for example, would not need support for. Note that a profile that specifies a file system but no symbolic links should also specify that symbolic link related errors shall not be returned by other file system functions (i.e. altered semantics resulting from profiling). Action: Move lstat(), readlink(), and symlink() from this option to a new profiling option before line 947 on page 25: _POSIX_SYMBOLIC_LINKS Symbolic Links lstat(), readlink(), symlink() [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 prindle@ieee.org (rdvk# 71) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_52 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 24 Line: 915 Section: 2.1.5.1 [prindle.xbd-17] Problem: The functions named glob() and globfree() belong in this profiling option group instead of in the _POSIX_SHELL profiling option group. In particular, the functions expand a wildcard pathname by searching for matching directories, a functionality certainly utilized by the shell, but not restricted for use by the shell or requiring shell support. Furthermore, they require searching file system directories, and for profiling purposes could not be provided on an implementation conforming to a profile in which the POSIX_FILE_SYSTEM unit of functionality is not required. Action: Add before link() the function names "glob()" and "globfree()" to this list. [Ed recommendation: DUP of prindle.xbd-32] _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 prindle@ieee.org (rdvk# 72) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 24 Line: 915 Section: 2.1.5.1 [prindle.xbd-18] Problem: The function named lchown() is an XSI function and does not belong in this profiling option group, but rather in the _XSI_FILE_SYSTEM profiling option group (see [prindle.xbd-XX]). Action: Remove this function name from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 prindle@ieee.org (rdvk# 73) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 922 Section: 2.1.5.1 [prindle.xbd-19] Problem: See also page 18, line 668 See also page 419, line 14581 The profiling option group is named _POSIX_MULTIPLE_PROCESS, but the corresponding 1003.13 unit of functionality is named POSIX_MULTI_PROCESS. This is likely to cause confusion. Action: Restore naming consistency by naming this profiling option group _POSIX_MULTI_PROCESS in all 3 places. [Ed recommendation: Accept] The draft has been marked up for unistd.h _____________________________________________________________________________ OBJECTION Enhancement Request Number 43 prindle@ieee.org (rdvk# 74) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 924 Section: 2.1.5.1 [prindle.xbd-20] Problem: The function named usleep() is an XSI function and does not belong in this profiling option group, but rather in the _XSI_MULTI_PROCESS profiling option group (see [prindle.xbd-XX]). Action: Remove this function name from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 44 prindle@ieee.org (rdvk# 317) [prindle.xbd-36] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 924 Section: 2.1.5.1 Problem: The functions named pclose() and popen() do not belong in this profiling option group, but rather in the _POSIX_SHELL_FUNC profiling option group. This is because, though they surely support spawning a new process, that process is implicitly a shell (i.e. the process image is not explicitly specified). No profile which includes a shell can fail to support multiple processes, so _POSIX_MULTIPLE_PROCESS will be implied by _POSIX_SHELL_FUNC and these functions don't need a separate profiling option group unto themselves. Action: Remove those 2 function names from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 45 prindle@ieee.org (rdvk# 75) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 931 Section: 2.1.5.1 [prindle.xbd-21] Problem: The external named h_errno is missing from this profiling option group (does not currently appear in any profiling option group). Action: Add before htonl() the external name "h_errno" to this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 46 prindle@ieee.org (rdvk# 81) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 932-933 Section: 2.1.5.1 [prindle.xbd-27] Problem: No functions named inet_lnaof(), inet_makeaddr(), inet_netof(), and inet_network() exist. Action: Remove those four function names from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 47 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 366) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 932 Section: omitted Problem: inet_pton() is missing from the list of _POSIX_NETWORKING functions Action: Add inet_pton() to the list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 prindle@ieee.org (rdvk# 316) [prindle.xbd-35] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 938 Section: 2.1.5.1 Problem: The symbol name _POSIX_SHELL is already taken (came from 1003.1a). That symbol indicates support for the shell itself. This profiling option indicates support for functions which utilize or implement a shell. It needs to be named something distinct. Action: Replace here and on page 18, line 671, "_POSIX_SHELL" with "_POSIX_SHELL_FUNC". Note: Do not change _POSIX_SHELL on page 415 line 14389 or in sysconf() in XSH. These are references to the true option, not the profiling option. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 49 prindle@ieee.org (rdvk# 318) [prindle.xbd-37] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 939 Section: 2.1.5.1 Problem: The functions named pclose() and popen() belong in this profiling option group instead of in the _POSIX_MULTIPLE_PROCESS profiling option group. Action: Add before system() the function names "pclose(), popen()," to this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 50 prindle@ieee.org (rdvk# 76) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_52 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 25 Line: 939 Section: 2.1.5.1 [prindle.xbd-22] Problem: The functions named glob() and globfree() do not belong in this profiling option group but rather in the _POSIX_FILE_SYSTEM profiling option group. In particular, the functions expand a wildcard pathname by searching for matching directories, a functionality certainly utilized by the shell, but not restricted for use by the shell or requiring shell support. Furthermore, they require searching file system directories, and for profiling purposes could not be provided on an implementation conforming to a profile in which the POSIX_FILE_SYSTEM unit of functionality is not required. Action: Remove these two function names from this list. [Ed recommendation: DUP of prindle.xbd-32] _____________________________________________________________________________ OBJECTION Enhancement Request Number 51 prindle@ieee.org (rdvk# 77) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 939 Section: 2.1.5.1 [prindle.xbd-23] Problem: The functions named regcomp(), regerror(), regexec(), and regfree() do not belong in this profiling option group, but rather in the _POSIX_C_LIB_EXT profiling option group (see [prindle.xbd-XX]). These functions constitute a generic string search (for regular expression) facility and operate as library functions (much the same as strstr(), for example) with no requirement for a shell, though they may certainly be utilized by a shell. Action: Remove these 4 function names from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 52 prindle@ieee.org (rdvk# 313) [prindle.xbd-32] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 939 Section: 2.1.5.1 Problem: [prindle.xbd-17] and [prindle.xbd-22] moved glob() and globfree() from _POSIX_SHELL (which incidentally needs its name changed - see [prindle.xbd-35]) to _POSIX_FILE_SYSTEM. Andrew pointed out that these functions were in _POSIX_SHELL because the operation they perform is unique to the shell and that profiles may wish to omit the functionality. However, they also do directory searches and therefore require file-system functionality. SSWG-RT proposes they therefore be assigned to a unique profiling option group that reflects that they perform file system functions but provide shell specific functionality. Action: Do not perform the actions in [prindle.xbd-17] and [prindle.xbd-22] - consider them OBE. Instead, move glob() and globfree() from page 25, line 939 to a new profiling option before line 918 on page 25: _POSIX_FILE_SYSTEM_EXT File System Extensions glob(), globfree() [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 53 prindle@ieee.org (rdvk# 319) [prindle.xbd-38] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 939 Section: 2.1.5.1 Problem: The functions regcomp(), regerror(), regexec(), and regfree() do not belong in this profiling option group. They neither require shell functionality nor implement functionality unique to the shell and utilities. Instead, they provide a generalized string search capability. However, they are much more advanced than the ISO functions like strstr() and strtok() and may not be required by simpler profiles for systems that do not typically support text manipulation. Therefore, they should be given a unique profiling option, _POSIX_REGEXP. Action: Move regcomp(), regerror(), regexec(), and regfree() from this option to a new profiling option before line 938 on page 25: _POSIX_REGEXP Regular Expressions regcomp(), regerror(), regexec(), regfree() [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 54 prindle@ieee.org (rdvk# 78) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 943 Section: 2.1.5.1 [prindle.xbd-24] Problem: The function named ualarm() is an XSI function and does not belong in this profiling option group, but rather in the _XSI_MULTI_PROCESS profiling option group (see [prindle.xbd-XX]). Action: Remove this function name from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 55 prindle@ieee.org (rdvk# 79) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 945 Section: 2.1.5.1 [prindle.xbd-25] Problem: The functions named environ() and errno() do not exist. Instead, the proper interfaces are the externally defined names environ and errno. Action: Remove the parentheses "()" from "environ()" and "errno()" and leave just "errno" and "environ". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 56 prindle@ieee.org (rdvk# 80) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 945 Section: 2.1.5.1 [prindle.xbd-26] Problem: The functions named ftime() and gettimeofday() are XSI functions and do not belong in this profiling option group, but rather in the _XSI_SINGLE_PROCESS profiling option group (see [prindle.xbd-XX]). Action: Remove this function name from this list. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 57 prindle@ieee.org (rdvk# 82) Thu, 25 Jan 2001 12:30:33 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 25 Line: 956 Section: 2.1.5.1 [prindle.xbd-28] Problem: Not every interface name in this standard belongs to either an option group or a profiling option group. Many such functions nonetheless need not be required in implementations supporting certain standard realtime (or other) profiles. To assist the profiling projects, new profiling option groups need to be created for XSI functionality that is not otherwise optional. Action: Add before this line the following additional profiling option groups: _XSI_C_LANG_SUPPORT XSI General C Library _longjmp() _setjmp() _tolower() _toupper() a64l() daylight drand48() erand48() erf() erfc() erfcf() erfcl() erff() erfl() ffs() getcontext() getdate() getsubopt() hcreate() hdestroy() hsearch() iconv() iconv_close() iconv_open() initstate() insque() isascii() j0() j1() jn() jrand48() l64a() lcong48() lfind() lrand48() lsearch() makecontext() memccpy() mrand48() nrand48() random() remque() scalb() seed48() setcontext() setstate() signgam srand48() srandom() strcasecmp() strdup() strfmon() strncasecmp() strptime() swab() swapcontext() tdelete() tfind() timezone() toascii() tsearch() twalk() wcswcs() wcswidth() wcwidth() y0() y1() yn() _XSI_DBM XSI Database Management dbm_clearerr() dbm_close() dbm_delete() dbm_error() dbm_fetch() dbm_firstkey() dbm_nextkey() dbm_open() dbm_store() _XSI_DEVICE_IO XSI Device Input and Output fmtmsg() poll() pread() pwrite() readv() writev() _XSI_DEVICE_SPECIFIC XSI General Terminal grantpt() ptsname() unlockpt() _XSI_DYNAMIC_LINKING XSI Dynamic Linking dlclose() dlerror() dlopen() dlsym() _XSI_FD_MGMT XSI File Descriptor Management truncate() _XSI_FILE_SYSTEM XSI File System basename() dirname() fchdir() fstatvfs() ftw() getwd() lchown() lockf() mknod() mkstemp() mktemp() nftw() realpath() seekdir() statvfs() sync() telldir() tempnam() utimes() _XSI_I18N XSI Internationalization catclose() catgets() catopen() nl_langinfo() _XSI_IPC XSI Interprocess Communication ftok() msgctl() msgget() msgrcv() msgsnd() semctl() semget() semop() shmat() shmctl() shmdt() shmget() _XSI_JOB_CONTROL XSI Job Control tcgetsid() _XSI_MULTI_PROCESS XSI Multiple Process getpgid() getpriority() getrlimit() getrusage() getsid() nice() setpgrp() setpriority() setrlimit() ulimit() usleep() vfork() waitid() _XSI_SIGNALS XSI Signal bsd_signal() killpg() sigaltstack() sighold() sigignore() siginterrupt() sigpause() sigrelse() sigset() ualarm() _XSI_SINGLE_PROCESS XSI Single Process ftime() gethostid() gettimeofday() putenv() _XSI_SYSTEM_DATABASE XSI System Database endpwent() getpwent() setpwent() _XSI_SYSTEM_LOGGING XSI System Logging closelog() openlog() setlogmask() syslog() _XSI_THREAD_MUTEX_EXT XSI Thread Mutex Extensions pthread_mutexattr_gettype() pthread_mutexattr_settype() _XSI_THREADS_EXT XSI Threads Extensions pthread_attr_getguardsize() pthread_attr_getstack() pthread_attr_setguardsize() pthread_attr_setstack() pthread_getconcurrency() pthread_setconcurrency() _XSI_TIMERS XSI Timers getitimer() setitimer() _XSI_USER_GROUPS XSI User and Group endgrent() endutxent() getgrent() getutxent() getutxid() getutxline() pututxline() setgrent() setregid() setreuid() setutxent() [Ed recommendation: Accept as marked] The set of related changes has been applied and a revised chapter is being recirculated. _____________________________________________________________________________________ EDITORIAL Enhancement Request Number 58 bouazza.bachar@compaq.comBug in XBDd5 Strictly Conforming XSI Application (rdvk# 97) {CPQ1} Mon, 29 Jan 2001 15:58:34 GMT _____________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The wording is correct as is. The committee acknowledges that the wording is difficult but that there is no better way to express it. The wording is taken from the .1a application conformance, which appears to have taken the best of the original .1 and .2 sections and reworked them some. The rationale from 1a states: This now aligns with Strictly Conforming POSIX.2 and also addresses WG15 document N374 and the IEEE 1003 System Services document N360 titled POSIX Conformance Issues. _____________________________________________________________________________________ Page: 36 Line: 1424 Section: Strictly Problem: minimums listed or being less than the maximums listed Action: maximums listed or being less than the minimums listed _____________________________________________________________________________________ EDITORIAL Enhancement Request Number 59 bouazza.bachar@compaq.comBug in XBDd5 Strictly Conforming XSI Application (rdvk# 96) {CPQ2} Mon, 29 Jan 2001 16:20:53 GMT _____________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: see the rationale for rejecting Number 58 _____________________________________________________________________________________ Page: 37 Line: 1468 Section: Strictly Problem: minimums listed or being less than the maximums listed Action: maximums listed or being less than the minimums listed _____________________________________________________________________________ EDITORIAL Enhancement Request Number 60 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 306) [DST-1999] Tue, 6 Feb 2001 22:07:05 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 37 Line: 1468 Section: 2.2.4 Problem: Missing text... line terminates in "in". Action: Add text macro; see line 1424, which seems correct. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 61 donnte@microsoft.com Bug in xbdd5 (rdvk# 20) [DST-4] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete the sentence starting "This facility.... supercomputer applications." on line 1601 _____________________________________________________________________________ Page: 42 Line: 1602 Section: Asynchronous Problem: I'm not sure what the sentence about "supercomputer applications" adds. It's not complete enough to develop intuition about the needs in that regard, and as it stands it's just a puzzlement. Action: Either delete or add "such as the need to ______" (Whatever ______ might be; I'm not sure, and if no one can fill in this blank off the top of their head, then I believe that it proves that the sentence is not useful.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 62 donnte@microsoft.com Bug in xbdd5 (rdvk# 21) [DST-5] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Person -> user _____________________________________________________________________________ Page: 45 Line: 1664 Section: Batch Problem: "person" is incorrect here. The neighborhood bag-lady could authorize me to be a batch administrator at Los Alamos, but it really wouldn't mean much. Action: Person -> "User ID". (Or anything that refers appropriately to a defined entity.) (If there's really a problem with the usage of the term, add the following: Note: This term is also applies to actions taken by a person using that User ID.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 63 donnte@microsoft.com Bug in xbdd5 (rdvk# 22) [DST-6] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 46 Line: 1693 Section: Batch Problem: The third paragraph (begining "The attributes") adds little and in fact is simply a tautology. (This, and many of the other definition changes below are simply intended to make this a proper (and useful) definition, not to change meaning.) Action: Delete. _____________________________________________________________________________ OBJECTION Enhancement Request Number 64 donnte@microsoft.com Bug in xbdd5 (rdvk# 23) [DST-7] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 47 Line: 1704 Section: Batch Problem: The first sentence is not useful as a definition, and again is a tautology. The second sentence/paragraph is a good definition as it stands. Action: Delete 1704. _____________________________________________________________________________ OBJECTION Enhancement Request Number 65 donnte@microsoft.com Bug in xbdd5 (rdvk# 24) [DST-8] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 47 Line: 1710 Section: Batch Problem: The first sentence is useless (nearly content free). The second sentence/ paragraph is a nice definition with very minor editing. Action: Delete 1710, Replace the beginning of 1711 with. "An attribute of a batch job which determines the types...". _____________________________________________________________________________ OBJECTION Enhancement Request Number 66 donnte@microsoft.com Bug in xbdd5 (rdvk# 25) [DST-9] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: person->user _____________________________________________________________________________ Page: 47 Line: 1726 Section: Batch Problem: "Person" again. (See DST-5) Action: "Person" -> User ID _____________________________________________________________________________ COMMENT Enhancement Request Number 67 donnte@microsoft.com Bug in xbdd5 (rdvk# 26) [DST-10] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete lines 1729-1730 , Delete "Such" on 1731, replace 1734-1735 with a xref to XCU 3.1.2 _____________________________________________________________________________ Page: 48 Line: 1729 Section: Batch Problem: This is a pretty long note at this point, and yet it is also unsatisfying by itself. Action: 1) Add a reference to the batch overview material (XCU Chapter 3). 2) Delete the existing note, and add "Note: Although the interfaces provided by the batch system are not strictly queues, the term is used for historical reasons." (Totally deleting the note would be OK with me.) 3) To the beginning of XCU 3.1.2 add A set of batch jobs is called a batch queue largely for historical reasons. Jobs are selected from the batch queue for execution based on attributes such as priority, resource requirements, and hold conditions. Batch jobs and batch queues are managed by a batch server. _____________________________________________________________________________ OBJECTION Enhancement Request Number 68 donnte@microsoft.com Bug in xbdd5 (rdvk# 27) [DST-11] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 48 Line: 1741 Section: Batch Problem: Useless tautology. Action: Delete 1741. _____________________________________________________________________________ OBJECTION Enhancement Request Number 69 donnte@microsoft.com Bug in xbdd5 (rdvk# 28) [DST-12] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 48 Line: 1743 Section: Batch Problem: The first paragraph is not really useful as a definition. With minor tweaks the 2d can be made into one. Action: Replace the whole section with: The place, relative to other jobs in the batch queue, occupied by a particular job in a batch queue. This is defined in part by submission time and priority; see also Section 3.62. _____________________________________________________________________________ OBJECTION Enhancement Request Number 70 donnte@microsoft.com Bug in xbdd5 (rdvk# 29) [DST-13] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "An attribute of a batch job indicating that it may be rerun after an abnormal termination from the beginning without affecting the validity of the results." _____________________________________________________________________________ Page: 48 Line: 1751 Section: Batch Problem: The first paragraph really isn't a useful definition and the 2'd won't work. Action: Replace the whole definition with: "An attribute of a batch job indicating that it may be rerun from the beginning without affecting the validity of the results." _____________________________________________________________________________ OBJECTION Enhancement Request Number 71 donnte@microsoft.com Bug in xbdd5 (rdvk# 30) [DST-14] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 49 Line: 1760 Section: Batch Problem: The first paragraph is not helpful as a definition. Action: Delete 1760; the remaining text works just fine as a definition. _____________________________________________________________________________ OBJECTION Enhancement Request Number 72 donnte@microsoft.com Bug in xbdd5 (rdvk# 31) [DST-15] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: person->user _____________________________________________________________________________ Page: 50 Line: 1785 Section: Batch Problem: Person, again. (See DST-5) Action: "A person" -> "A User ID". _____________________________________________________________________________ OBJECTION Enhancement Request Number 73 donnte@microsoft.com Bug in xbdd5 (rdvk# 32) [DST-16] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A property of an open file description that causes it to wait for the requested action to be performed before returning. _____________________________________________________________________________ Page: 50 Line: 1798 Section: Blocking Problem: This simply isn't right, in that it says nothing about FDs, but its antonym "Non-blocking" does. Action: Inverting the text for Non-Blocking: A property of an open file descritpn that causes it to wait for the requested action to be performed before returning. If this was an attempt to generalize beyond FDs (as it appears to be), then try this: A property specified as part of the explicit or implied attributes of an operation which causes it to wait until the requested operation has been completed before proceeding with the execution of the program. (However, if you use this, I suspect that "Non-Blocking" should be rephrased similarly, as they are intended as antonyms.) (Or, if it's suitable, a IEEE dictionary definition would work.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 74 Joseph S. Myers BUG in XBDd5 (rdvk# 52) [JSM-9] Tue, 16 Jan 2001 09:50:42 +0000 (GMT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_76 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1829-1840 Section: Byte Problem: The definition of byte here does not account for the requirement for int8_t in , which means that bytes need to be 8 bits for POSIX. Action: Change "equal to or larger than an octet" to "equal to an octet". Change "bits, number of which is implementation-defined" to "eight bits". Change "clarify its intent" to "clarify its intent (and align with the requirement for exact-width eight bit integer types in , which means that bytes must have exactly eight bits)". Remove from "It deviates intentionally" to end of line 1840. _____________________________________________________________________________ OBJECTION Enhancement Request Number 75 Jon Hitchcock Bug in XBDd5 Byte (rdvk# 323) {jjh15} Tue, 13 Feb 2001 13:01:28 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See 76 which is in direct conflict with the proposed action here. _____________________________________________________________________________ Page: 51 Line: 1829-1840 Section: Byte Problem: Changing the definition of "Byte" (JSM-9) is a bad idea. Traditionally, UNIX has not been tied to any particular hardware, and this principle has been one reason for its success over the last 30 years. Who knows what will happen in the next 30 years. Hardware designers might say: "In order to simplify the wiring in the memory and cache, we have made the smallest addressable unit 64 bits. The extra speed is so great that users will not mind wasting 7/8ths of the memory when storing ASCII characters." If so, it would be a pity if POSIX implementations had to run in a slow emulation mode, just because all the text allowing bytes to be larger than 8 bits had been removed back in 2001. Especially if the change was a result of decisions made without considering all the consequences. Action: Do not change the definition, and resolve the problem another way. Some suggestions are: Change int8_t to some other type. Prohibit Posix conforming programs from testing to see if int8_t is implemented using part of a larger item by the compiler hiding the existence of the padding bits. Add a note saying that the size of a byte had inadvertently been restricted to 8 bits in this version of the standard, and that this restriction may be removed in future versions. _____________________________________________________________________________ OBJECTION Enhancement Request Number 76 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 367) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (an OR vote was taken on this item) Change the entire section to: An individually addressable unit of data storage that is exactly an octet, used to store a character or a portion of a character; see also Section 3.87 (on page 52). A byte is composed of a contiguous sequence of 8 bits. The least significant bit is called the low-order bit; the most significant is called the the high-order bit. Note: The definition of byte from the ISO C standard is broader than the above and might accomodate hardware architectures with different sized addressable units than octets. Add to XRAT page 3308 before line 399 (section A.3 definitions) The restriction that a byte is now exactly eight bits was a conscious decision by the standard developers. It came about due to a combination of factors, primarily the use of the type int8_t within the networking functions and the alignment with C99, where the intN_t types are now defined. According to C99: * The [u]intN_t types must be two's complement with no padding bits and no illegal values. * All types (apart from bitfields, which aren't relevant here) must occupy an integral number of bytes. * If a type with width W occupies B bytes with C bits per byte (C is the value of CHAR_BIT), then it has P padding bits where P+W = B*C. * For int8_t we therefore have P=0, W=8. Since B>=1, C>=8, the only solution is B=1, C=8. The standard developers also felt that this was not an undue restriction for the current state of the art for this revision of IEEE Std 1003.1-200x, but recognize that if industry trends continue, a wider character type may be required in the future. _____________________________________________________________________________ Page: 51 Line: 1830-1840 Section: omitted Problem: It is not in practice possible to conform to this standard without having an addressable (by C) unit of exactly 8 bits. Don't pretend that we can. This is really a flaw in C99, but that's not in our power to change. Action: Change the entire section to: An individually addressable unit of data storage that is exactly an octet, used to store a character or a portion of a character; see also Section 3.87 (on page 52). A byte is composed of a contiguous sequence of 8 bits. The least significant bit is called the low-order bit; the most significant is called the the high-order bit. Note: The definition of byte from the ISO C standard is broader than the above and might accomodate hardware architectures with different sized addressable units than octets. This standard can not be complied with on such architectures. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 77 donnte@microsoft.com Bug in xbdd5 (rdvk# 33) [DST-17] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 60 Line: 2069 Section: Empty Problem: Missing comma for readability. Action: "to it in decimal" -> "to it, in decimal". [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 78 donnte@microsoft.com Bug in xbdd5 (rdvk# 34) [DST-18] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 61 Line: 2096 Section: Era Problem: Wrong case. Action: Initial "a" -> "A". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 79 Joseph S. Myers BUG in XBDd5 (rdvk# 53) [JSM-7] Tue, 16 Jan 2001 09:04:00 +0000 (GMT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 65 Line: 2180-2185 Section: File Problem: The existing POSIX.1 and POSIX.2 standards (ISO/IEC 9945-1:1996 and ISO/IEC 9945-2:1993) use the terms "filename" and "pathname" (as does the online Single Unix Specification). The change to "file name" and "path name" (with spaces) is gratuitous (though I'd welcome pointers to where, in either the draft itself or online Austin Group documents, the rationale for this change can be found). Furthermore, it breaks existing practice that "file name" is a synonym for "pathname"; "file name" is the recommended terminology in the GNU Coding Standards. Thus, this change breaks a substantial body of widely distributed and used documentation. ISO/IEC 9945-2:1993(E) (joint ISO/IEC/IEEE printing), page 771, lines 706-711 documents the existing use of "file name" to mean "pathname", and its exclusion from the standard because of potential confusion with "filename". Though it was excluded from the standard, the terminology "file name" should not now be adopted for any other use because of the confusion resulting and incompatibility with existing documentation. Action: Throughout XBD, XSH, XCU and XRAT, revert "file name" and "path name" to the current POSIX terminology "filename" and "pathname". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 80 donnte@microsoft.com Bug in xbdd5 (rdvk# 35) [DST-19] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 84 Line: 2708 Section: Pseudo-Terminal Problem: Not a definition (begins with the defined term). Action: "A...with an interface" -> "A facility that provides an interface..." _____________________________________________________________________________ COMMENT Enhancement Request Number 81 donnte@microsoft.com Bug in xbdd5 (rdvk# 36) [DST-20] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 98 Line: 3061 Section: Tab Problem: Grammar Action: "The is the character" -> "It is the character..." (I first noticed this with , but the whole family of symbols which have \x designations in C have the same problem (although this for some reason reads worse than the others).) I believe that it also makes a better-formed definition to make this change. (And it should be made in all such places in the defintions, look for "is the character".) [Ed recommendation: Accept] [do globally to the definitions] _____________________________________________________________________________ OBJECTION Enhancement Request Number 82 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 116) [DST-92] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3324 Section: 4.4 Problem: Shallification Action: access is determined as -> access, access shall be determined as [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 83 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 117) [DST-93] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3326 Section: 4.4 Problem: Shallification Action: requested, access is -> requested, access shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 84 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 118) [DST-94] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3327 Section: 4.4 Problem: Shallification Action: requested, access is granted if -> requested, access shall be granted if [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 85 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 119) [DST-95] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3329 Section: 4.4 Problem: Shallification Action: otherwise, access is -> otherwise, access shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 86 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 120) [DST-96] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3333 Section: 4.4 Problem: Shallification Action: Access is granted if -> Access shall be granted if [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 87 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 121) [DST-97] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108 Line: 3336 Section: 4.4 Problem: Shallification Action: otherwise, access is -> otherwise, access shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 88 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 122) [DST-98] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 109 Line: 3363 Section: 4.7 Problem: Shallification Action: marked fields are set to -> marked fields shall be set to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 89 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 123) [DST-99] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 109 Line: 3364 Section: 4.7 Problem: Shallification Action: update marks are cleared. -> update marks shall be cleared. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 90 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 124) [DST-100] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3397 Section: 4.10 Problem: Shallification Action: fails if this cannot be accomplished. -> shall fail if this cannot be accomplished. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 91 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 125) [DST-101] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3398 Section: 4.10 Problem: Shallification Action: path name is taken to -> path name shall be taken to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 92 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 126) [DST-102] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3400 Section: 4.10 Problem: Shallification Action: path name is taken to -> path name shall be taken to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 93 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 127) [DST-103] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3425 Section: 4.10 Problem: Shallification Action: name dot refers to the -> name dot shall refer to the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 94 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 128) [DST-104] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3426 Section: 4.10 Problem: Shallification Action: name dot-dot refers to the -> name dot-dot shall refer to the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 95 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 129) [DST-105] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110 Line: 3428 Section: 4.10 Problem: Shallification Action: single slash resolves to the -> single slash shall resolve to the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 96 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 130) [DST-106] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 111 Line: 3446 Section: 4.12 Problem: Shallification; "shall" is a magic word... use it. Action: Conforming implementations are required to define the -> Conforming implementations shall define the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 97 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 131) [DST-107] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 111 Line: 3448 Section: 4.12 Problem: Shallification Action: conforming implementations define in -> conforming implementations shall define in [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 98 pete.forman@westerngeco.com BUG in XBDd5 (rdvk# 2) [PWF20001220/1] Wed, 20 Dec 2000 14:10:45 +0000 (GMT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The term adds no further clarity or crispness to the definition. The original term has been in common usage since 1970 and the the change proposed would lead to a decrease in consensus. _____________________________________________________________________________ Page: 111 Line: 3451 Section: 4.13 Problem: The term "Seconds Since the Epoch" is misleading. This section adequately defines what is meant by the term but the term itself should be clearer. It implies that it is a true count rather than an encoding of the broken-down time. This is confusing to those who read other sections of the standard that make use of the term but who have not read this section. I would suggest renaming this section to "Pseudo-seconds Since the Epoch", and updating references to the term. The Chambers Dictionary gives one definition of "pseudo-" as "deceptively resembling". This ERN is not seeking to sort out shortcomings in POSIX time keeping, just to clarify what is being specified. Issues such as fractions of seconds, TAI v. UTC v. civil time, leap seconds, ordering timestamps, and calculating time differences should be addressed elsewhere. (Proposals have been made to alter the definition in this section so that time_t does indeed represent the number of seconds since epoch. IMHO these are flawed. Some of the arguments were expounded on the Austin group mailing list in 2000-10 "Bug in XRATd4 (defect in CLOCK_REALTIME?)" and elsewhere.) References to time since the Epoch in XSHd5 page 675 line 6905 section clock_getres() need not be updated as these functions deal with several types of clock. Action: Change "Seconds Since the Epoch" to "Pseudo-seconds Since the Epoch" Also at page 61 line 2088 section 4.149 Epoch comment page 370 line 12899 section comment page 433 line 15194 section comment page 461 line 814 section Index comment And others in XSHd5, e.g. page 724 line 8335 section ctime() comment And others in XCUd5, e.g. page 2323 line 4068 section 3.2.2.1 comment And others in XRATd5, e.g. page 3334 line 1439 section A.4.13 comment [Ed recommendation: I believe this was somewhat covered in the review in draft 4, that the consensus was to stay with the current definition which has been around since 1988 and that the changes proposed would lead to a decrease in consensus, and should be rejected.] _____________________________________________________________________________ COMMENT Enhancement Request Number 99 gwinn@res.ray.com Bug in XBDd5 4.13 Seconds Since the Epoch (rdvk# 311) {0102-1 } Mon, 12 Feb 2001 04:13:32 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 111 Line: 3461 Section: 4.13 Problem: Suggest adding a note stating that the divisions in the formula on lines 3461-3463 are integer. That is, the remainder is discarded, leaving only the integer quotient. Action: See problem. [Ed recommendation: Accept as marked. Add to the existing note on 3742: The divisions in the formular are integer divisions, that is, the remainder is discarded leaving only the integer quotient.] _____________________________________________________________________________ COMMENT Enhancement Request Number 100 gwinn@res.ray.com Bug in XBDd5 4.13 Seconds Since the Epoch (rdvk# 310) {0102-2 } Mon, 12 Feb 2001 04:15:46 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 111 Line: 3470 Section: 4.13 Problem: The sentence "The first adds ..." has an ambiguous reference. Action: Change the sentence to read "The first term adds ...", adding the clarifying word "term". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 101 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 132) [DST-108] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3486 Section: 4.14 Problem: Shallification Action: the value is -> the value shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 102 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 133) [DST-109] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3490 Section: 4.14 Problem: Shallification Action: semaphore value is -> semaphore value shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 103 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 134) [DST-110] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3499 Section: 4.16 Problem: Shallification Action: There is a one-to-one -> There shall be a one-to-one [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 104 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 135) [DST-111] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3501 Section: 4.16 Problem: Shallification Action: is generated automatically from a -> shall be generated automatically from a [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 105 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 136) [DST-112] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3506 Section: 4.16 Problem: Shallification Action: trace event is of a -> trace event shall be of a [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 106 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 137) [DST-113] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3507 Section: 4.16 Problem: Shallification Action: trace point generates a trace -> trace point shall generate a trace [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 107 donnte@microsoft.com Bug in xbdd5 (rdvk# 37) [DST-21] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 113 Line: 3527 Section: 4.16 Problem: This one-line paragraph really is the first sentence of the following paragraph (which continues the same thought). Action: Join to next paragraph. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 108 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 138) [DST-114] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 113 Line: 3528 Section: 4.16 Problem: Shallification Action: such mapping is associated with each trace stream.-> such mapping shall be associated with each trace stream. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 109 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 139) [DST-115] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 113 Line: 3528 Section: 4.16 Problem: Use the right word (to, rather than if). Action: An active trace stream is associated to -> An active trace stream is associated with [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 110 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 140) [DST-116] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3551 Section: 4.16 Problem: Shallification Action: This operation causes all -> This operation shall cause all [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 111 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 141) [DST-117] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3552 Section: 4.16 Problem: Shallification Action: trace stream behaves as if -> trace stream shall behave as if [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 112 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 142) [DST-118] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3554 Section: 4.16 Problem: Shallification x 2 Action: event names is not cleared. -> event names shall not be cleared. the trace log is also reinitialized. -> the trace log shall also be reinitialized. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 113 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 143) [DST-119] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3556 Section: 4.16 Problem: Shallification Action: trace log is recorded when -> trace log shall be recorded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 114 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 144) [DST-120] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3561 Section: 4.16 Problem: Shallification Action: traced process is traced together -> traced process shall be traced together [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 115 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 145) [DST-121] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3562 Section: 4.16 Problem: Shallification Action: trace stream is -> trace stream shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 116 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 146) [DST-122] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 114 Line: 3581 Section: 4.16 Problem: Shallification Action: controller process is shut down -> controller process shall be shut down [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 117 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 147) [DST-123] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3597 Section: 4.17.1 Problem: Shallification Action: the function returns an implementation-defined -> the function shall return an implementation-defined [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 118 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 148) [DST-124] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3604 Section: 4.17.2 Problem: Shallification Action: the function returns the value -> the function shall return the value [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 119 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 149) [DST-125] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3616 Section: 4.17.3.1 Problem: Shallification Action: function returns the value -> function shall return the value [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 120 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 150) [DST-126] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3624 Section: 4.17.3.2 Problem: Shallification Action: the function returns an -> the function shall return an [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 121 donnte@microsoft.com Bug in xbdd5 (rdvk# 47) [DST-88] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agreed that there is a problem , that this is inconsistent with the use elswhere. Change: XBD p 116 line 3644 Either, the integer expression (math_errhandling & MATH_ERRNO) is non-zero and errno shall be set to [EDOM], or the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero and the invalid floating-point exception shall be raised. to If the integer expression (math_errhandling & MATH_ERRNO) is non-zero then errno shall be set to [EDOM]. If the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero then the invalid floating-point exception shall be raised. We Need to change occurrences (in the maths functions) of "Either, the integer expression and .... or the integer expression and.... ." to "If the integer expression then.... . If the integer expression then.... ." Luckily we used stdinclude files and so only need to edit 4 files in in Text/Stdmathtext/ maths-domerr:Either, the integer expression (math_errhandling & MATH_ERRNO) is maths-polerr:Either, the integer expression (math_errhandling & MATH_ERRNO) is maths-reoverflow:Either, the integer expression (math_errhandling & MATH_ERRNO) is maths-reunderflow:Either, the integer expression (math_errhandling & MATH_ERRNO) is ( These are included in the following interfaces: acos.mm acosh.mm asin.mm asinh.mm atan.mm atan2.mm atanh.mm ceil.mm cos.mm cosh.mm erf.mm erfc.mm exp.mm exp2.mm expm1.mm fdim.mm floor.mm fma.mm fmod.mm hypot.mm ilogb.mm j0.mm ldexp.mm lgamma.mm llrint.mm llround.mm log.mm log10.mm log1p.mm log2.mm logb.mm lrint.mm lround.mm nearbyint.mm nextafter.mm pow.mm remainder.mm remquo.mm rint.mm round.mm scalb.mm scalbln.mm sin.mm sinh.mm sqrt.mm tan.mm tanh.mm tgamma.mm y0.mm) _____________________________________________________________________________ Page: 115 Line: 3644 Section: 4.18 Problem: "Either/or" is confusing here because, according to math.h, BOTH bits can be set (line 9664). (Either/or implies exclusive or.) Action: Change "Either, the" to "If", and ", or the" to ". If" (The uses of the same expressions on the prior page are not parenthesized; be consistent, one way or another.) (This could also be very usefully recast to "with the usual consequences", with a good definition of "usual consequences" in one place to be referred to here, the text on 115, and the bunch of places in XSH where this happens.) [Ed recommendation: None we believe the "either" is intentional, mandating one of the two behaviors, we have also used this construct extensively in the maths pages. We do accept the note about paranthesization ] _____________________________________________________________________________ COMMENT Enhancement Request Number 122 donnte@microsoft.com Bug in xbdd5 (rdvk# 38) [DST-22] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3631 Section: 4.18 Problem: As the text reads, this is really explicitly talking about "isnan" alone, as its the only function with a NaN argument (type, sort of). Action: "For functions with" -> "For functions called with". [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 123 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 151) [DST-127] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3637 Section: 4.18 Problem: Shallification Action: error and return a -> error and shall return a [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 124 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 152) [DST-128] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 116 Line: 3638 Section: 4.18 Problem: "May" is a reserved word, and we're making an observation here, not granting permission. Avoid may for observations. (If might be that C grants permission here, but if so, it's not ours to do.) Action: The function may never see the signaling NaN, since it may trigger when -> The function might never see the signaling NaN, since it might trigger when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 125 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 153) [DST-129] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 117 Line: 3665 Section: 4.20 Problem: Shallification Action: value parts meet the -> value parts shall meet the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 126 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 155) [DST-131] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3700 Section: 4.20 Problem: Looking at this list, it's inconsistent whether the sentence is a description starting with a verb ("Attempts") or an imperiative statement ("Attempt"). The changes below make the list consistent and use the imperative form (with "you shall" implied before the verb.) Action: Attempts to alert -> Attempt to alert [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 127 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 156) [DST-132] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3701 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 128 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 157) [DST-133] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3703 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 129 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 158) [DST-134] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3705 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 130 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 159) [DST-135] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3706 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 131 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 160) [DST-136] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3707 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 132 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 161) [DST-137] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3710 Section: 4.20 Problem: Consistency, use imperative. Action: Moves the printing -> Move the printing [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 133 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 154) [DST-130] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3713 Section: 4.20 Problem: The standard is discussing file formats at this point; the shall in the sentence below is making a requirement on the standard (that we write the standard correctly). That's an improper use of "shall", as it's not making a conformance requirement. Each conversion specification shall be introduced by the percent-sign character ('%'). Action: shall be -> is _____________________________________________________________________________ OBJECTION Enhancement Request Number 134 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 162) [DST-138] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 120 Line: 3737 Section: 4.20 Problem: Shallification Action: The value is to be converted -> The value shall be converted [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 135 donnte@microsoft.com Bug in xbdd5 (rdvk# 39) [DST-23] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 121 Line: 3744 Section: File Problem: (Yeah, this is old territory, but persistence....) First, let me say that this generally is a signficant improvement in readability. Then, let me say.... :-). The hanging tag on this line is in Roman, unquoted. Yet when it refers to itself two lines later (on 3746) it's quoted constant-width font. That's not really readable/understandable unless you already know what it's intended to mean. Action: Code the flag characters identically to the conversion specifiers: always CW, not quoted. (These are PRINTF flag characters, not COMMAND flag characters,so if that consistency is an issue, they are different objects.) [Ed recommendation: Accept as marked we will change the 0 to CW, the convention is for quoted characters inline and unquoted in lists --see xxiii ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 136 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 163) [DST-139] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: -> "(or in style F or E in the case of "G")" _____________________________________________________________________________ Page: 121 Line: 3783 Section: 4.20 Problem: The 'f' form can yield letters (NaN and Inf), which are sensitive to the case of the 'f' operator; so this should read: Action: -> "(or in style F or E in the case of "G")" (Or use the similar text for printf, if you prefer.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 137 Clive D.W. Feather Bug in XBDd5 character sets (rdvk# 113) [CDWF-522] Fri, 2 Feb 2001 15:05:18 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is a requirement from previous POSIX versions, applications depend on it. It is also in C99 section 5.2.1 para 2. _____________________________________________________________________________ Page: 126 Line: 3951 Section: 6.1 Problem: The ISO C Standard does not have a concept of "all bits zero" in this context. The actual requirement on NUL is on line 3954, which is that it is zero when stored into a char object. Action: Replace line 3951 with: * A null character, NUL, shall be in the set of characters. _____________________________________________________________________________ OBJECTION Enhancement Request Number 138 Clive D.W. Feather Bug in XBDd5 character sets (rdvk# 114) [CDWF-523] Fri, 2 Feb 2001 15:05:18 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Although this section overlaps with C99, this section contains POSIX requirements from earlier POSIX standards and is not intended to be an extension to C99 and should stand alone in its own rights. _____________________________________________________________________________ Page: 126 Line: 3952-3954 Section: 6.1 Problem: The requirements in this paragraph come from the C Standard, but that standard only applies them to its own concept of "portable character set", which isn't the same as POSIX's. The differences are the dollar, at, and grave characters. Action: That depends on how you want to extend C99 in this area. For example, you could make the rules apply to these characters, in which case: CX shade lines 3831, 3864, and 3901 or you could exclude these characters from the rule, in which case: Append to line 3954: These requirements do not apply to , , or . _____________________________________________________________________________ OBJECTION Enhancement Request Number 139 jeffcope@microsoft.com bugs in xbd (rdvk# 308) [JLC-1] Fri, 9 Feb 2001 10:32:38 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: We could not find any contradictions in the text. This section was added in 1003.2b. _____________________________________________________________________________ Page: 126 Line: 3957 Section: 6.2 Problem: Sections 6.2 and 6.4.1 cover the same material and are not completely in agreement. Action: Change the sentence beginning at 3961 to "In locales other than the POSIX locale, a character may have a state-dependent encoding. There are two types of these encodings, a single-shift encoding and a locking-shift encoding, both of which are described in detail in section 6.4.1." Move the information in the three paragraphs from lines 3963 through 3981 to 6.4.1, at line 4158, which makes the current par at 4158 redundant. Also, this move points out that the sentence beginning "If the implementation..." at the end of line 4164 is a clearer rendition of the description of locking-shift than the change-barred description at 3873ff. _____________________________________________________________________________ OBJECTION Enhancement Request Number 140 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 164) [DST-140] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3968 Section: 6.2 Problem: Shallification Action: Std 1003.1-200x support it. -> Std 1003.1-200x shall support it. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 141 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 165) [DST-141] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3977 Section: 6.2 Problem: Shallification Action: character set retain their -> character set shall retain their [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 142 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 166) [DST-142] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3978 Section: 6.2 Problem: Shallification Action: interpretation and do not alter -> interpretation and shall not alter [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 143 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 167) [DST-143] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3979 Section: 6.2 Problem: Shallification x 2 Action: sequence is a function of the current shift state. -> sequence shall be a function of the current shift state. A byte with all bits zero is interpreted as -> A byte with all bits zero shall be interpreted as [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 144 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 168) [DST-144] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3982 Section: 6.2 Problem: Shallification Action: current locale is indicated -> current locale shall be indicated [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 145 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 169) [DST-145] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 126 Line: 3985 Section: 6.2 Problem: Shallification Action: a character is defined by -> a character shall be defined by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 146 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 170) [DST-146] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 127 Line: 3998 Section: 6.3 Problem: Shallification Action: Character Set equals its value -> Character Set shall equal its value [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 147 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 171) [DST-147] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 127 Line: 4000 Section: 6.3 Problem: Shallification Action: shift bytes do not have -> shift bytes shall not have [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 148 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 234) [DST-210] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 128 Line: 4024 Section: 6.4 Problem: This table, table 10-1, and the similar one in the stty command (objection below) seem excessively redundant. Action: Delete table 6-2, and change all references to it to read "the Value column of table 10-1". [Ed recommendation: Reject, this table calls out a specific set of control characters, and so making the change proposed would change the requirement over the Base document, POSIX 1003.2-1992, page 42, ll1194-, clause 2.4.1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 149 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 172) [DST-148] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4031 Section: 6.4 Problem: Shallification Action: Each consists of the -> Each shall consist of the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 150 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 173) [DST-149] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4038 Section: 6.4 Problem: Shallification Action: This defaults -> This shall default [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 151 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 174) [DST-150] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4043 Section: 6.4 Problem: Shallification Action: are interpreted -> shall be interpreted [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 152 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 175) [DST-151] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "The escape character" to "The character" on line 4043 _____________________________________________________________________________ Page: 128 Line: 4044 Section: 6.4 Problem: Omitted word Action: This used -> This is used [Ed recommendation: None There is no "This used" on this line. Need further information] _____________________________________________________________________________ OBJECTION Enhancement Request Number 153 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 176) [DST-152] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4044 Section: 6.4 Problem: Shallification Action: This defaults -> This shall default [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 154 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 177) [DST-153] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4048 Section: 6.4 Problem: Shallification x 2 Action: the line is to be ignored. -> the line shall be ignored. The default character is the -> The default character shall be the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 155 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 178) [DST-154] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4060 Section: 6.4 Problem: Shallification Action: mapping definition defines a single -> mapping definition shall define a single [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 156 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 179) [DST-155] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 128 Line: 4065 Section: 6.4 Problem: Shallification Action: mapping definition defines a range -> mapping definition shall define a range [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 157 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 180) [DST-156] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4076 Section: 6.4 Problem: Shallifcation grammar (shall...defines is wrong; prior fix didn't go far enough.) Action: and defines the coded -> and define the coded [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 158 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 181) [DST-157] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4087 Section: 6.4 Problem: Shallification Action: Decimal constants are represented by -> Decimal constants shall be represented by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 159 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 182) [DST-158] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4089 Section: 6.4 Problem: Shallification Action: Hexadecimal constants are represented by -> Hexadecimal constants shall be represented by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 160 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 183) [DST-159] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4091 Section: 6.4 Problem: Shallification Action: constants are represented by -> constants shall be represented by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 161 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 184) [DST-160] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 129 Line: 4101 Section: 6.4 Problem: "is undefined" is simpler, and then we don't have to ask what "undefined results" are. Action: produces undefined results. -> is undefined. [Ed recommendation: Reject The wording is as per the Base document. Restating it as undefined makes the sentence meaningless. We believe "produces undefined results" is clear] _____________________________________________________________________________ OBJECTION Enhancement Request Number 162 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 185) [DST-161] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 129 Line: 4102 Section: 6.4 Problem: Shallification Action: encoded value is the value -> encoded value shall be the value _____________________________________________________________________________ OBJECTION Enhancement Request Number 163 donnte@microsoft.com Bug in xbdd5 (rdvk# 40) [DST-24] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At XBD 4104, insert a sentence between the existing ones: Bytes shall be treated as unsigned octets, and carry shall be propagated between the bytes as necessary to represent the range. XBD Chapter 6 On page 127, line 3989 remove ", larger bytes" On page 129, line 4093 remove the sentence beginning "Implementations supporting..." Chapter 7 On page 136, delete lines 4328-4329. XSH pthread_attr_destroy On page 1487, line 31469, change 8-bit -> 8-bits, 16-bit -> 16-bits (first one). XCU cksum On page 2459 on line 9511 delete "moving 8-bit characters into 9-bit bytes or" XCU uuencode On page 3180, delete lines 37070-37073. _____________________________________________________________________________ Page: 129 Line: 4111 Section: Character Problem: Makes a requirement without a shall. A requirement in an example. A grammar problem (missing 'in'). I don't see any other text that requires the carry out from a low byte to a higher byte in a multibyte character. Thus, this example is carrying the burden of being normative text when it shouldn't. (Note also the requirement that it's an unsigned 8-bit carry.) Action: 1) Add normative text making the requirement. I'm not expert enough to suggest proper normative text here; it should come from an i18n person. 2) "Note that ...example" -> "Note that this line is interpreted as IN the example...". _____________________________________________________________________________ OBJECTION Enhancement Request Number 164 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 186) [DST-162] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 130 Line: 4136 Section: 6.4 Problem: "is undefined" is simpler, and then we don't have to ask what "undefined results" are. Action: WIDTH declaration produces undefined -> WIDTH declaration is undefined [Ed recommendation: Reject, produces undefined results is clearer, the proposal has no meaning] _____________________________________________________________________________ COMMENT Enhancement Request Number 165 donnte@microsoft.com Bug in xbdd5 (rdvk# 41) [DST-25] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_139 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 131 Line: 4158 Section: 6.4.1 Problem: This text seems highly redundant with that at 3963. I'm not sure what the objective of the repitition is. Action: If it's redundant, remove one instance and cross reference as needed. If it's not redundant, make it clearer what the distinction being made is. (I fully agree with the content, just have a problem with the redundancy that appears to serve no purpose.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 166 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 187) [DST-163] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_139 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 131 Line: 4169 Section: 6.4.1 Problem: It appears that at line 3968, single-shift (state dependent) encodings is implementation defined here. At 4169, it appears to require that they work right. In general 6.2 and 6.4.1 appear to be redundant, and conflicting. Action: I'm not going to try to ajudicate which of the two is right, that's for the i18n mavens. However, my objection is to the existence of both these sections (6.2 and 6.4.1). Remove one (and reconcile as necessary). _____________________________________________________________________________ OBJECTION Enhancement Request Number 167 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 188) [DST-164] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 134 Line: 4219 Section: 7.2 Problem: Shallification Action: POSIX locale is -> POSIX locale shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 168 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 189) [DST-165] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 137 Line: 4362 Section: 7.3.1 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 169 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 190) [DST-166] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 137 Line: 4365 Section: 7.3.1 Problem: Shallification Action: uppercase letters are -> uppercase letters shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 170 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 191) [DST-167] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 137 Line: 4372 Section: 7.3.1 Problem: Shallification Action: lowercase letters are -> lowercase letters shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 171 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 192) [DST-168] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 137 Line: 4378 Section: 7.3.1 Problem: Shallification Action: and lower are -> and lower shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 172 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 193) [DST-169] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 137 Line: 4385 Section: 7.3.1 Problem: Shallification Action: are included. -> shall be included. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 173 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 194) [DST-170] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4396 Section: 7.3.1 Problem: Shallification Action: and are -> and shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 174 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 195) [DST-171] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4403 Section: 7.3.1 Problem: Shallification Action: or print are -> or print shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 175 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 196) [DST-172] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4408 Section: 7.3.1 Problem: Shallification Action: or cntrl are -> or cntrl shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 176 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 197) [DST-173] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4413 Section: 7.3.1 Problem: Shallification Action: punct are included -> punct shall be included [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 177 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 198) [DST-174] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4414 Section: 7.3.1 Problem: Shallification Action: class cntrl are -> class cntrl shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 178 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 199) [DST-175] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4420 Section: 7.3.1 Problem: Shallification Action: class graph are included -> class graph shall be included [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 179 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 200) [DST-176] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 138 Line: 4421 Section: 7.3.1 Problem: Shallification Action: class cntrl are -> class shall be [Ed recommendation: Accept as marked] [class cntrl are -> class cntrl shall be] _____________________________________________________________________________ OBJECTION Enhancement Request Number 180 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 201) [DST-177] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 138 Line: 4428 Section: 7.3.1 Problem: Shallification Action: are included. -> shall be included. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 181 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 202) [DST-178] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4437 Section: 7.3.1 Problem: Shallification Action: and are -> and shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 182 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 203) [DST-179] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4442 Section: 7.3.1 Problem: Shallification Action: class name consists of at -> class name shall consist of at [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 183 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 204) [DST-180] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4461 Section: 7.3.1 Problem: Shallification Action: are mapped to the corresponding 26 uppercase characters: -> shall be mapped to the corresponding 26 uppercase characters: [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 184 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 205) [DST-181] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4463 Section: 7.3.1 Problem: Shallification Action: the operand consists of character -> the operand shall consist of character [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 185 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 206) [DST-182] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4464 Section: 7.3.1 Problem: Shallification Action: character pair are separated by -> character pair shall be separated by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 186 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 207) [DST-183] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 140 Line: 4474 Section: 7.3.1 Problem: Shallification Action: are mapped to the corresponding 26 lowercase characters: -> shall be mapped to the corresponding 26 lowercase characters: [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 187 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 208) [DST-184] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 140 Line: 4476 Section: 7.3.1 Problem: Shallification Action: the operand consists of character -> the operand shall consist of character [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 188 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 209) [DST-185] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 140 Line: 4477 Section: 7.3.1 Problem: Shallification Action: character pair are separated by -> character pair shall be separated by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 189 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 210) [DST-186] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4729 Section: 7.3.2 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 190 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 211) [DST-187] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4735 Section: 7.3.2 Problem: Shallification Action: This statement is followed by -> This statement shall be followed by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 191 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 212) [DST-188] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 152 Line: 5052 Section: 7.3.3 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 192 jeffcope@microsoft.com bugs in xbd (rdvk# 312) [JLC-3] Mon, 12 Feb 2001 11:09:14 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete the sentences beginning "In contexts..." on lines 5063,5069 _____________________________________________________________________________ Page: 152 Line: 5064 Section: 7.3.3 [This supercedes my original objection at this page/line. Thanks to Clive Feather for pointing out the appropriate C standard bits, and helping to clarify my thoughts on the matter.] Problem: "In contexts where standards (such as the ISO C standard) limit the mon_decimal_point to a single byte,..." should be removed. Consider the case where you want a Euro sign (almost certainly a multi-byte character) to be the decimal separator, as one example of the problem. Similarly for thousands separator, which in the ISO paperwork is a thin space (again, almost certainly represented by a multi-byte sequence). Action: Change the sentence to "In contexts where standards (such as the ISO C standard) limit mon_decimal_point to a single byte, this standard explicitly allows a multiple-byte value." and mark the line as CX. Make a similar change in the description of mon_thousands_sep beginning at 5069. _____________________________________________________________________________ OBJECTION Enhancement Request Number 193 jeffcope@microsoft.com bugs in xbd (rdvk# 309) [JLC-2] Fri, 9 Feb 2001 10:32:38 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 152 Line: 5064 Section: 7.3.3 Problem: "In contexts where standards (such as the ISO C standard) limit the mon_decimal_point to a single byte." doesn't apply any more. Both mon_decimal_point and mon_thousands_sep are char * in the C99 standard. Action: Remove the specified sentence, and the similar sentence in the description of mon_thousands_sep beginning at 5069. [Ed recommendation: Reject, withdrawn by originator, see JLC-3] _____________________________________________________________________________ OBJECTION Enhancement Request Number 194 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 213) [DST-189] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_192 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 152 Line: 5065 Section: 7.3.3 Problem: decimal delimiter (radix character) in monetary formatted quantities. In contexts where standards (such as the ISO C standard) limit the mon_decimal_point to a single byte, the result of specifying a multi-byte 7.11.2.1 of c99 doesn't appear to limit this to being a single byte character any longer. Action: If that's the case, the sentence "In contexts..." can be deleted (here and elsewhere nearby that it may appear). If it isn't the case (that it is a byte), it probably should be "a single byte *character*" we're qualifying the character, not the storage space in which it appears. _____________________________________________________________________________ COMMENT Enhancement Request Number 195 drepper@redhat.com Bug in XBDd5 Locale Definition (rdvk# 7) {ud-11} Thu, 21 Dec 2000 22:36:16 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 153 Line: 5117 Section: Locale Problem: C99 introduced in the struct lconv structure a six new elements: int_p_cs_precedes int_n_cs_precedes int_p_sep_by_space int_n_sep_by_space int_p_sign_posn int_n_sign_posn All the other elements of struct lconv have equivalents in the locale definition for the LC_MONETARY category but not these new ones. Action: Add after line 5116: int_p_cs_precedes An integer set to 1 if the int_curr_symbol precedes the value for a monetary quantity with a non-negative value, and set to 0 if the symbol succeeds the value. int_n_cs_precedes An integer set to 1 if the int_curr_symbol precedes the value for a monetary quantity with a negative value, and set to 0 if the symbol succeeds the value. int_p_sep_by_space An integer set to 0 if no space separates the int_curr_symbol from the value for a monetary quantity with a non-negative value, set to 1 if a space separates the symbol from the value, and set to 2 if a space separates the symbol and the sign string, if adjacent. int_n_sep_by_space An integer set to 0 if no space separates the int_curr_symbol from the value for a monetary quantity with a negative value, set to 1 if a space separates the symbol from the value, and set to 2 if a space separates the symbol and the sign string, if adjacent. int_p_sign_posn An integer set to a value indicating the positioning of the positive_sign for a positive monetary quantity formatted with the international format. int_n_sign_posn An integer set to a value indicating the positioning of the negative_sign for a negative monetary quantity formatted with the international format. If this is accepted the work-around for the omission in C90 in the descriptions of the other fields must be removed as well: l 5090: remove "or int_curr_symbol" l 5093: remove "or int_curr_symbol" l 5097: remove "or int_curr_symbol" l 5100: remove "or int_curr_symbol" l 5107: remove "or int_curr_symbol" l 5109: remove "or int_curr_symbol" l 5111: remove "or int_curr_symbol" l 5113: remove "or int_curr_symbol" l 5114: remove "or int_curr_symbol" Replace line 5106 with: values shall be recognized for p_sign_posn, n_sign_posn, int_p_sign_posn, and int_n_sign_posn: ________________________________________________________________________________ COMMENT Enhancement Request Number 196 Jon.Hitchcock@uniplex.co.ukBug in XBDd5 LC_MONETARY and LC_NUMERIC (rdvk# 365) {jjh51} Wed, 14 Feb 2001 20:36:02 GMT ________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: There is historic practise for input to be both ways. The maintainer of glibc accepts that this was a bug in the glibc version shipped with Red Hat Linux 6.2 ________________________________________________________________________________ Page: 154, Line: 5148, Section: LC_MONETARY Problem: An experiment on Tru64 Unix 5.0A shows that with the default (POSIX) locale, or with no "grouping" in the input to localedef, localeconv() returns grouping="". But with "grouping -1" in the input to localedef (), localeconv() returns grouping="\177". So if the localedef input specified for the POSIX locale at line 5206 ("grouping -1") is used on this system, the result from localconv() does not conform to line 5213 (which specifies a value of ""). An experiment on Red Hat 6.2 shows that with the default (POSIX) locale, localeconv() returns grouping="\177". This does not conform to line 5213. Since the values "" and "\177" both mean that there is no grouping, either value should be allowed. Likewise for mon_grouping. (In fact, Red Hat 6.2 returns grouping="", but this does not change the general argument.) Also, the localedef input for mon_grouping in the POSIX locale is given as -1 at line 5129 and as "" at line 5148. Action: Change "localeconv() Value" at lines 5148 and 5213 to say that it is either an empty string or a string of one character with the value CHAR_MAX. Change "localedef Value" at line 5148 to say -1. _____________________________________________________________________________ OBJECTION Enhancement Request Number 197 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 214) [DST-190] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 155 Line: 5175 Section: 7.3.4 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 198 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 215) [DST-191] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 156 Line: 5223 Section: 7.3.5.1 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 199 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 216) [DST-192] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: There are no specific recommendations with ISO 8601 regarding use of BC/AD. The IEEE position is that either way is acceptable. The Open Group preference is with the existing text. The review group feels the existing text is more easily recognizable. _____________________________________________________________________________ Page: 157 Line: 5278 Section: 7.3.5.1 Problem: Political correctness: it's my understanding that we should now be using "Common Era" and "Before Common Era" (altho apparently AD is OK). For example, the Christian era BC starts on the day before January 1, Yevette, what's right? Action: Should be Common, 'BCE'. [Ed recommendation: Reject, this note is clear its the Christian era] _____________________________________________________________________________ OBJECTION Enhancement Request Number 200 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 217) [DST-193] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 158 Line: 5315 Section: 7.3.5.2 Problem: Only LC_TIME gets a discussion of the XSI extensions; none of the other LC_* categories do: 7.3.5.2 LC_TIME C-Language Access Action: In order of preference: 1) Remove this, and rely on the other nl_langinfo pages to do the work. (Could this be an unintended vestigal section?) 2) Move this to 7.3.5.3 (and 7.3.5.3 becomes 7.3.5.2) so at least all the section numbers remain parallel. 3) Put in the corresponding stuff for the other LC_* categories (in which case, I don't care if (2) is done, as long as all the sections look similar, so it's clear we intended whatever we did. [Ed recommendation: Reject Reject option 1 and 3: This section is here since there is an XSI extension to LC_TIME. This placement was intentional so that the "category" appears last in each section in chapter 7.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 201 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 218) [DST-194] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 162 Line: 5490 Section: 7.3.6 Problem: Shallification Action: existing locale to be used -> existing locale which shall be used [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 202 Jon.Hitchcock@uniplex.co.uk Bug in XBDd5 LC_MESSAGES (rdvk# 364) {jjh50} Wed, 14 Feb 2001 19:38:41 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 162 Line: 5498 Section: LC_MESSAGES Problem: There is no explanation of yesstr and nostr. Action: Add after line 5498: The locale definition grammar allows the obsolete keywords yesstr and nostr to be included in the locale definition file. They have no effect. [Ed recommendation: Accept as marked Remove lines 5708-5709 of the grammar, since they were LEGACY in a previous issue this would be the next logical step] _____________________________________________________________________________ OBJECTION Enhancement Request Number 203 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 219) [DST-195] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 171 Line: 5812 Section: 8.1 Problem: Shallification Action: names do not contain -> names shall not contain [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 204 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 220) [DST-196] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 171 Line: 5818 Section: 8.1 Problem: Improper shall: Making a requirement on the standard. Action: Std 1003.1-200x shall consist solely -> Std 1003.1-200x consist solely _____________________________________________________________________________ OBJECTION Enhancement Request Number 205 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 221) [DST-197] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 171 Line: 5819 Section: 8.1 Problem: Improper shall: Making a requirement on the standard. (This is the minimum change; if you want to say "and won't in the future" (in proper standardese) that's fine with me.) Action: and shall not begin -> and do not begin _____________________________________________________________________________ OBJECTION Enhancement Request Number 206 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 222) [DST-198] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 171 Line: 5821 Section: 8.1 Problem: Shallification Action: lowercase letters retain their -> lowercase letters shall retain their [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 207 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 223) [DST-199] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 171 Line: 5825 Section: 8.1 Problem: Unneeded (and confusing) "also" (the "other" part of the "also" isn't obvious and it adds nothing.) Action: applications may also have difficulty -> applications may have difficulty [Ed recommendation: Accept This is editorial] _____________________________________________________________________________ OBJECTION Enhancement Request Number 208 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 224) [DST-200] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 172 Line: 5858 Section: 8.1 Problem: Shallification Action: utility, they are given the -> utility, they shall be given the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 209 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 225) [DST-201] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 175 Line: 5999 Section: 8.3 Problem: Shallification Action: determines the number of columns -> shall determine the number of columns [Ed recommendation: Reject The style through POSIX.1/POSIX.2 has been for unspecified and implementation-defined items to be in present tense (is / are/ determines) and not shallified, and this would seem to be in current style.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 210 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 226) [DST-202] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 175 Line: 6014 Section: 8.3 Problem: Shallification Action: the implementation determines the number -> the implementation shall determine the number [Ed recommendation: Reject as per the previous item] _____________________________________________________________________________ OBJECTION Enhancement Request Number 211 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 227) [DST-203] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 176 Line: 6031 Section: 8.3 Problem: Shallification Action: The prefixes are separated by -> The prefixes shall be separated by [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 212 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 228) [DST-204] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 176 Line: 6032 Section: 8.3 Problem: Shallification Action: a slash is inserted between -> a slash shall be inserted between [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 213 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 229) [DST-205] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 176 Line: 6037 Section: 8.3 Problem: Shallification Action: The list is searched -> The list shall be searched [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 214 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 230) [DST-206] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 176 Line: 6041 Section: 8.3 Problem: Shallification Action: path prefixes is not performed. -> path prefixes shall not be performed. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 215 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 231) [DST-207] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 177 Line: 6085 Section: 8.3 Problem: Shallification Action: this case do not include -> this case shall not include [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 216 keld@dkuug.dk bugs in d5 (rdvk# 337) [KS-4] Wed, 14 Feb 2001 09:02:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "character" to "single-character collating element" in line 6272. In other words, change from: A matching list expression specifies a list that shall match any character in any of the expressions represented in the list. to: A matching list expression specifies a list that shall match any single-character collating element in any of the expressions represented in the list. The intent was to require matching only for single-character collating elements, and to leave it unspecified for multi-character collating elements. _____________________________________________________________________________ Page: 181 Line: 6272 Section: regexp Problem: The text as it stands now seems to restrict the matching to only apply to characters, while the correct unit of matching is collating elements. The LC_COLLATE category that regexps are defined on only describes collating elements in its definition, not characters. Action: Change "character" to "collating element" in line 6272 _____________________________________________________________________________ OBJECTION Enhancement Request Number 217 keld@dkuug.dk bugs in d5 (rdvk# 334) [KS-1] Wed, 14 Feb 2001 09:02:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: It is not clear what the "correct" behavior should be for multi-character collating elements. For example, in a Danish locale where "aa" is a collating element, ISO POSIX-2: 1993 and common existing practice agree that "[a][a]" matches "aa", even though many Danes would disagree. Conversely, ISO POSIX-2: 1993 requires that "[^[:alpha:]]" matches "aa", even though common existing practice and most Danes would disagree. We did not achieve universal consensus about what the "correct" behavior should be in troublesome cases like these. However, because of these disagreements among the standard, common existing practice, and user expectations, the consensus was to make the behavior unspecified in these cases. _____________________________________________________________________________ Page: 181 Line: 6274-6276 Section: regexp Problem: Multi-character collation elements need to be handled correctly, as it is also specified in ISO/IEC 9945-2:1993. Action: Delete the sentence on multicharacter collating elements in line 6274-6276 _____________________________________________________________________________ OBJECTION Enhancement Request Number 218 keld@dkuug.dk bugs in d5 (rdvk# 338) [KS-5] Wed, 14 Feb 2001 09:02:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "character" to "single-character collating element" in line 6278. In other words, change from: 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 after the leading circumflex. to: A non-matching list expression begins with a circumflex ('^'), and specifies a list that shall match any single-character collating element except for the expressions represented in the list after the leading circumflex. Please see the XBD ERN 216 rationale for related discussion. _____________________________________________________________________________ Page: 181 Line: 6278 Section: regexp Problem: The text as it stands now seems to restrict the matching to only apply to characters, while the correct unit of matching is collating elements. The LC_COLLATE category that regexps are defined on only describes collating elements in its definition, not characters. Action: Change "character" to "collating element" in line 6278 _____________________________________________________________________________ OBJECTION Enhancement Request Number 219 keld@dkuug.dk bugs in d5 (rdvk# 335) [KS-2] Wed, 14 Feb 2001 09:02:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Please see the XBD ERN 217 rationale. _____________________________________________________________________________ Page: 181 Line: 6280-6281 Section: regexp Problem: Multi-character collation elements need to be handled correctly, as it is also specified in ISO/IEC 9945-2:1993. Action: Delete the sentence on multicharacter collating elements in line 6280-6281 _____________________________________________________________________________ OBJECTION Enhancement Request Number 220 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 232) [DST-208] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 182 Line: 6254 Section: 9.3.5 Problem: Shallification Action: RE that matches -> RE that shall match [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 221 keld@dkuug.dk bugs in d5 (rdvk# 336) [KS-3] Wed, 14 Feb 2001 09:02:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the sentence in lines 6303-6304 from: A character class expression shall represent the set of characters belonging to a character class, as defined in the LC_CTYPE category in the current locale. to: A character class expression shall represent the the union of two sets: (1) the set of single-character collating elements whose characters belong to the character class, as defined in the LC_CTYPE category in the current locale, and (2) an unspecified set of multi-character collating elements. The enhancement request's basic idea is a good one, but unfortunately the request as worded would invalidate existing conforming implementations. The change above allows both the requested and the ISO POSIX-2: 1993 behavior. Also please see the response to XRAT ERN 9. _____________________________________________________________________________ Page: 182 Line: 6303-6310 Section: regexp Problem: Multi-character collation elements do not have associated character class properties for the whole collating element, but only for each of the characters involved. The question is then how to construct the character class for the whole collation element. Analysis: Multi-character collation elements are normally digraphs or trigraphs, like Danish "aa" which is considered one letter and actually a variant of the letter "e". As the collating elements normally consists of all letters, there is no doubt for the classes alphe, alnum, blank, cntrl, digit, graph, print, punct, space and xdigit. The only problem is for the classes lower and upper. If the collation element begin with a uppercase, like the "Aa" in "Aagaard" then it should be considered uppercase, otherwise if it begins with a lowercase, it should be considered lowercase. Thus the attributes of the first character in the multi-character collation element would determine the character class of the collation element. Action: Add after line 6310 : "Multi-character collation elements have no character attributes assigned to the whole collation element, and the attribute of the first character of the collation element is then used." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 222 gwc@unisoft.com BUG in XBDd5 (vertical bars) (rdvk# 9) {gwc vertical bars} Wed, 3 Jan 2001 18:42:08 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 190-193 Line: 6610-6718 Section: 9.5 Problem: Almost all of the vertical bar (|) characters have disappeared from the RE grammar. E.g. line 6610 should be: | L_ANCHOR not just: L_ANCHOR It looks like wherever a vertical bar was the first non-whitespace character on a line, it has been moved to become a change-bar. So perhaps the problem is caused by the new change-bar software that was used for this draft, and the vertical bar characters are still intact in the document source. A quick look at some other grammars shows they are affected as well, so probably all of the grammars are the same, or maybe even every vertical bar character that is not in amongst other text. Action: If the problem is with the change-bar software (i.e. the document source is still OK), then either fix the software or protect the vertical bar characters from it somehow. If the document source has been changed, the best way to fix it (i.e. the least likely to introduce new errors) would probably be to restore all the affected subsections from draft 4 and then reapply the draft 4 aardvark. Someone needs to check all the other grammars, and other places where vertical bar characters appear, and fix them in the same way. [Ed recommendation: Accept, see d5-update-1.pdf for a set of fixed pages] _____________________________________________________________________________ OBJECTION Enhancement Request Number 223 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 233) [DST-209] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 195 Line: 6740 Section: 10.1 Problem: Use the proper permission granting word, "may". Action: files. Applications are allowed to create files -> files. Applications may create files [Ed recommendation: Accept as marked Change: Applications are allowed -> Applications shall be allowed as per 1003.2-1992] _____________________________________________________________________________ COMMENT Enhancement Request Number 224 donnte@microsoft.com Bug in xbdd5 (rdvk# 43) [DST-27] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 195 Line: 6753 Section: 10.1 Problem: "It shall provide..." is ambiguous in several ways: 1) It allows record I/O (like to a tape drive). (Altho I HAVE seen card reader/punch pairs used in lieu of a console, which gets interesting if you have to copy the card on an interpreting card punch to read the message.) 2) "System Console" is undefined. Action: Try: "It shall provide an interface conforming to the requirements of the terminal interface section to an implementation-defined device or pseudo-device which is conventionally called the 'System Console'. The System Console need not be the controlling termnal for any process. It is unspecified whether it is possible for a read to succeed on this device." [Ed recommendation: Accept as marked below: On item 2 , System Console is defined in 3.382, although this looks to me as if the definition needs some furthe rework Recommended change The /dev/console file is a generic name given to the system console (xref to 3.382). It is usually linked to an implementation-defined special file. It shall provide an interface to the system console conforming to the requirements of the terminal interface section of IEEE Std 1003.1-200x Change 3.382 An implementation-defined device that receives messages sent by the syslog() function, and the fmtmsg() function when the MM_CONSOLE flag is set. Change p 96 l 3020 "fmtmsg() is defined" to "fmtmsg() and syslog() functions are defined" ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 225 donnte@microsoft.com Bug in xbdd5 (rdvk# 42) [DST-26] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 195 Line: 6753 Section: 10.1 Problem: "machine-dependent" isn't defined. Action: "machine-dependent" -> "implementation defined". [Ed recommendation: Accept as marked implementation-defined (with a hyphen)] _____________________________________________________________________________ OBJECTION Enhancement Request Number 226 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 235) [DST-211] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_148 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 196 Line: 6777 Section: 10.2 Problem: This table, table 6-2, and the similar one in the stty command (objection below) seem excessively redundant. Action: Delete table 6.2, and change all references to read "the value column of table 10.1". (No change here, this is a landmark, but one does have to wonder if the material on serial lines, including this table, wouldn't better fit in chapter 11.) [Ed recommendation: Duplicate See rdvk #234, DST-210 This was dealt with earlier, see the earlier duplicate rdvk] _____________________________________________________________________________ COMMENT Enhancement Request Number 227 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 332) [Robert.Barned@lmco.com] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We discussed with the originator. Some of the requested changes were felt not to be acceptable. There are still some applications and devices that rely on the current definitions and change would adversely affect them. We were able to achieve consensus on the following change below: at line 7195 (replace 2nd sentence with) The symbols in the following table shall be defined in , not all values specified are required to be supported by the underlying hardware _____________________________________________________________________________ Page: 203-209 Line: all Section: all Problem: The constants associated with terminals are out of date. This increases the cost of computer systems as interface manufactures think they need to do testing for hardware that no longer is used. This is especially true of constants on page 206. Action: Update constants as requested. [Ed recommendation: NONE Further information has been requested of this balloter, specifically we need a proposal of which constants should be updated] _____________________________________________________________________________ OBJECTION Enhancement Request Number 228 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 236) [DST-212] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 197 Line: 6804 Section: 11.1.1 Problem: Shallification Action: it normally causes the thread -> it normally shall cause the thread [Ed recommendation: Reject The cases where this is happens are described correctly using shall in the following section. This wording is also as per the Base document and my recommendation is to leave it as is.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 229 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 237) [DST-213] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6914 Section: 11.1.6 Problem: Shallification Action: device, it is a limit -> device, it shall be a limit [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 230 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 238) [DST-214] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6916 Section: 11.1.6 Problem: Shallification Action: defined, there is no such -> defined, there shall be no such [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 231 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 239) [DST-215] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6918 Section: 11.1.6 Problem: Shallification Action: This processing affects data in -> This processing shall affect data in [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 232 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 240) [DST-216] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6920 Section: 11.1.6 Problem: Shallification Action: ERASE character deletes the last -> ERASE character shall delete the last [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 233 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 241) [DST-217] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6921 Section: 11.1.6 Problem: Shallification Action: KILL character deletes all data -> KILL character shall delete all data [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 234 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 242) [DST-218] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 199 Line: 6922 Section: 11.1.6 Problem: Shallification Action: KILL characters have no -> KILL characters shall have no [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 235 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 243) [DST-219] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6923 Section: 11.1.6 Problem: Shallification Action: characters themselves are not placed in -> characters themselves shall not be placed in [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 236 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 244) [DST-220] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6926 Section: 11.1.7 Problem: Shallification Action: kill processing do not occur. -> kill processing shall not occur. [Ed recommendation: Accept] Action: _____________________________________________________________________________ OBJECTION Enhancement Request Number 237 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 245) [DST-221] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6938 Section: 11.1.7 Problem: Shallification Action: inter-byte timer and is activated after -> inter-byte timer which shall be activated after _____________________________________________________________________________ OBJECTION Enhancement Request Number 238 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 246) [DST-222] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6939 Section: 11.1.7 Problem: Shallification Action: timer, it is reset after -> timer, it shall be reset after [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 239 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 247) [DST-223] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6940 Section: 11.1.7 Problem: Shallification Action: inter-byte timer is started. -> inter-byte timer shall be started. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 240 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 248) [DST-224] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6942 Section: 11.1.7 Problem: Shallification Action: the read is satisfied. -> the read shall be satisfied. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 241 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 249) [DST-225] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6943 Section: 11.1.7 Problem: Shallification x 2 Action: that point are returned to the user. -> that point shall be returned to the user. Note that if TIME expires at least one byte -> Note that if TIME expires at least one byte shall [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 242 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 250) [DST-226] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6946 Section: 11.1.7 Problem: In this case, "the data" is wrong... it's "if there is data in the buffer" (See also -1990). Action: If the data is -> If data is [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 243 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 251) [DST-227] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6947 Section: 11.1.7 Problem: In this case, "the data" is wrong... it's "if there is data in the buffer" (See also -1990). Action: as if the data has -> as if data has [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 244 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 252) [DST-228] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6950 Section: 11.1.7 Problem: Shallification Action: pending read is not satisfied until -> pending read shall not be satisfied until [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 245 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 253) [DST-229] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6955 Section: 11.1.7 Problem: Shallification x 2 Action: timer that is activated as soon as -> timer that shall be activated as soon as A read is satisfied as -> A read shall be satisfied as [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 246 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 254) [DST-230] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6956 Section: 11.1.7 Problem: Shallification Action: no bytes are returned. -> no bytes shall be returned. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 247 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 255) [DST-231] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6960 Section: 11.1.7 Problem: In this case, "the data" is wrong... it's "if there is data in the buffer" (See also -1990). Action: data. If the data is -> data. If data is [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 248 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 256) [DST-232] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 200 Line: 6961 Section: 11.1.7 Problem: In this case, "the data" is wrong... it's "if there is data in the buffer" (See also -1990). Action: as if the data has -> as if data has [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 249 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 257) [DST-233] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6977 Section: 11.1.9 Problem: Shallification Action: INTR character is -> INTR character shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 250 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 258) [DST-234] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6981 Section: 11.1.9 Problem: Shallification Action: Quit character is discarded -> Quit character shall be discarded [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 251 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 259) [DST-235] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6986 Section: 11.1.9 Problem: Shallification Action: ERASE character is discarded when -> ERASE character shall be discarded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 252 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 260) [DST-236] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6989 Section: 11.1.9 Problem: Shallification Action: character is discarded when -> character shall be discarded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 253 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 261) [DST-237] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6995 Section: 11.1.9 Problem: Shallification Action: EOF character is discarded when -> EOF character shall be discarded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 254 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 262) [DST-238] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 7000 Section: 11.1.9 Problem: Shallification Action: SUSP character causes a SIGTSTP -> SUSP character shall cause a SIGTSTP [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 255 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 263) [DST-239] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 7002 Section: 11.1.9 Problem: Shallification Action: SUSP character is discarded when -> SUSP character shall be discarded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 256 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 264) [DST-240] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7006 Section: 11.1.9 Problem: Shallification Action: STOP character is discarded when -> STOP character shall be discarded when [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 257 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 265) [DST-241] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7009 Section: 11.1.9 Problem: Shallification Action: START character is -> START character shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 258 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 266) [DST-242] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7024 Section: 11.1.9 Problem: Shallification Action: functions are recognized only -> functions shall be recognized only [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 259 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 267) [DST-243] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7027 Section: 11.1.9 Problem: Shallification Action: no special function occurs. -> no special function shall occur. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 260 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 268) [DST-244] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7031 Section: 11.1.10 Problem: Shallification Action: SIGHUP signal is sent to -> SIGHUP signal shall be sent to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 261 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 269) [DST-245] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 202 Line: 7032 Section: 11.1.10 Problem: Shallification Action: made, this causes the controlling -> made, this shall cause the controlling [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 262 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 270) [DST-246] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 203 Line: 7059 Section: 11.2.2 Problem: We define the symbols in the table, that's not a "shall" (here), altho it's clearly a shall on the implementor there. Action: this table shall be defined in -> this table are defined in [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 263 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 271) [DST-247] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 204 Line: 7087 Section: 11.2.2 Problem: Shallification Action: break) is given to -> break) shall be given to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 264 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 272) [DST-248] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 204 Line: 7090 Section: 11.2.2 Problem: Shallification Action: than break) is -> than break) shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 265 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 273) [DST-249] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7162 Section: 11.2.3 Problem: Shallification Action: of 0 indicates no delay. -> of 0 shall indicate no delay. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 266 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 274) [DST-250] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7163 Section: 11.2.3 Problem: Shallification Action: fill characters are transmitted for -> fill characters shall be transmitted for [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 267 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 275) [DST-251] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7164 Section: 11.2.3 Problem: Shallification Action: the fill character is -> the fill character shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 268 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 276) [DST-252] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7166 Section: 11.2.3 Problem: Shallification Action: specified, it lasts for about -> specified, it shall last for about [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 269 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 277) [DST-253] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7167 Section: 11.2.3 Problem: Shallification x 2 Action: New-line delay lasts about 0.10 seconds. -> New-line delay shall last about 0.10 seconds. If ONLRET is set, the carriage-return delays are -> If ONLRET is set, the carriage-return delays shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 270 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 278) [DST-254] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 205 Line: 7168 Section: 11.2.3 Problem: Shallification Action: fill characters are -> fill characters shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 271 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 279) [DST-255] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7169 Section: 11.2.3 Problem: Shallification x 2 Action: type 1 is dependent on the current column position -> type 1 shall be dependent on the current column position type 2 is about -> type 2 shall be about [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 272 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 280) [DST-256] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7170 Section: 11.2.3 Problem: Shallification x 2 Action: type 3 is about 0.15 seconds -> type 3 shall be about 0.15 seconds. If OFILL is set, delay type 1 transmits two -> If OFILL is set, delay type 1 shall transmit two [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 273 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 281) [DST-257] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7172 Section: 11.2.3 Problem: Shallification x 2 Action: type 1 is dependent on the current column position. -> type 1 shall be dependent on the current column position. Type 2 is about -> Type 2 shall be about [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 274 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 282) [DST-258] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7174 Section: 11.2.3 Problem: Shallification Action: characters are transmitted for -> characters shall be transmitted for [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 275 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 283) [DST-259] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7175 Section: 11.2.3 Problem: Shallification Action: Backspace delay lasts about 0.05 seconds. -> Backspace delay shall last about 0.05 seconds. If OFILL is set, one fill character is -> If OFILL is set, one fill character shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 276 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 284) [DST-260] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7181 Section: 11.2.4 Problem: We define the symbols in the table, that's not a "shall" (here), altho it's clearly a shall on the implementor there. Action: this table shall be defined in -> this table are defined in [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 277 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 285) [DST-261] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7208 Section: 11.2.4 Problem: Shallification (and proper word use) Action: terminal device do not become effective -> terminal device shall not become effective not all errors are detected -> not all errors need be detected [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 278 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 286) [DST-262] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7210 Section: 11.2.4 Problem: Shallification Action: CSIZE bits specify the -> CSIZE bits shall specify the [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 279 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 287) [DST-263] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 7213 Section: 11.2.4 Problem: Shallification Action: does not include the parity -> shall not include the parity bit, [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 280 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 288) [DST-264] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7217 Section: 11.2.4 Problem: Shallification x 2 Action: enabled, PARODD specifies odd parity if set; -> enabled, PARODD shall specify odd parity if set; otherwise, even parity -> otherwise, even parity shall be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 281 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 289) [DST-265] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7222 Section: 11.2.4 Problem: Shallification Action: a connection does not depend -> a connection shall not depend [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 282 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 290) [DST-266] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7229 Section: 11.2.4 Problem: Use proper "need not". Action: baud rate may or may not be -> baud rate need not be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 283 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 291) [DST-267] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7235 Section: 11.2.5 Problem: We define the symbols in the table, that's not a "shall" (here), altho it's clearly a shall on the implementor there. Action: this table shall be defined in -> this table are defined in [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 284 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 292) [DST-268] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7251 Section: 11.2.5 Problem: Use right verb. Action: If there were no character -> If there is no character [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 285 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 293) [DST-269] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 7252 Section: 11.2.5 Problem: Granting permission; use "may". Action: an implementation might echo an -> an implementation may echo an [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 286 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 294) [DST-270] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 208 Line: 7263 Section: 11.2.5 Problem: Shallification Action: implementation-defined functions are recognized from -> implementation-defined functions shall be recognized from [Ed recommendation: Accept as per Base document] _____________________________________________________________________________ OBJECTION Enhancement Request Number 287 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 295) [DST-271] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 208 Line: 7277 Section: 11.2.5 Problem: Shallification Action: that process is output to -> that process shall be output to [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 288 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 296) [DST-272] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 208 Line: 7278 Section: 11.2.5 Problem: Shallification Action: SIGTTOU signal is not -> SIGTTOU signal shall not be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 289 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 297) [DST-273] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 214 Line: 7434 Section: 12.2 Problem: This is sticky. This appears to be stating a requirement, which in at least a couple of cases is not honored, and in general this chunk of text is "should" anyway. (Altho it is given "shall" status in some situations.) I think it should be "should" to conform to the rest of the section. (It shouldn't be "are" in any case.) Action: Multi-digit options are not -> Multi-digit options should not be [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 290 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 368) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 218 Line: 7573 Section: omitted Problem: INET6_ADDRSTRLEN should be IP6 shaded. Action: Shade "and INET6_ADDRSTRLEN" IP6. _____________________________________________________________________________ OBJECTION Enhancement Request Number 291 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 298) [DST-274] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The originator agreed to withdraw this item _____________________________________________________________________________ Page: 233 Line: 8066 Section: fcntl.h Problem: Improper shall: Shall on the document doen't work. Action: and SEEK_END shall be defined -> and SEEK_END are defined _____________________________________________________________________________ OBJECTION Enhancement Request Number 292 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 299) [DST-275] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: as 291 _____________________________________________________________________________ Page: 234 Line: 8085 Section: fcntl.h Problem: Improper shall: Shall on the document doen't work. Action: of mode_t shall be defined as described -> of mode_t are described _____________________________________________________________________________ OBJECTION Enhancement Request Number 293 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 300) [DST-276] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 234 Line: 8109 Section: fcntl.h Problem: "defined as described"... A special from the Department of Repetitive Redundancy Department... Action: pid_t types shall be defined as described in -> pid_t types are defined in _____________________________________________________________________________ EDITORIAL Enhancement Request Number 294 pete.forman@westerngeco.com BUG in XBDd5 (rdvk# 3) [PWF20001220/2] Wed, 20 Dec 2000 14:10:45 +0000 (GMT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 235 Line: 8143 Section: Problem: Typo. Action: Change "" to "" [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 295 Clive D.W. Feather Bug in XBDd5 (rdvk# 102) [CDWF-518] Wed, 31 Jan 2001 22:46:42 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 238 Line: 8264-8271 Section: fenv.h Problem: This text talks about defining macros such as FE_INEXACT if the implementation doesn't do so. These names are reserved, and an application *must* not define them. [For example, other macros might expand in ways that rely on this name not being defined.] Action: Replace this text with: Macros corresponding to unsupported modes and rounding directions are not defined by the implementation and must not be defined by the application. An application might use #ifdef to test for this. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 296 Jon.Hitchcock@uniplex.co.uk Bug in XBDd5 langinfo.h (rdvk# 362) {jjh45} Wed, 14 Feb 2001 15:24:49 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 257 Line: 8848 Section: langinfo.h Problem: Use of singular verb. Action: Change "value for p_cs_precedes and n_cs_precedes does not match" to "values for p_cs_precedes and n_cs_precedes do not match" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 297 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 360) {jjh36} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This change was felt to be unnecessary _____________________________________________________________________________ Page: 260 Line: 8904 Section: limits.h Problem: Refering the reader to XSH section 2.2 to find "the appropriate feature test macro" suggests that the macro name for each symbol or for each header is given there explicitly. In fact there may be more than one feature test macro that will make the symbol visible. Action: Change "the appropriate" to "a", here and for other headers that have similar comments. _____________________________________________________________________________ OBJECTION Enhancement Request Number 298 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 301) [DST-277] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: In this case the wording was felt to be more desirable. _____________________________________________________________________________ Page: 261 Line: 8938 Section: limits.h Problem: We have the right term, use it. (Arguably, intdeterminate is mathematically more precise, but we do have a specific term for this.) Action: indeterminate. -> unspecified. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 299 donnte@microsoft.com Bug in xbdd5 (rdvk# 44) [DST-28] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 9494 Section: limits.h Problem: As for other nearby similar instances, make this a (tabular) list, rather than doing it as inline text. (Long words don't work this way.) Action: Tabular list. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 300 Clive D.W. Feather Bug in XBDd5 (rdvk# 107) [CDWF-516] Wed, 31 Jan 2001 11:18:13 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 274 Line: 9507-9509 Section: locale.h Problem: Since this header includes CX-marked text, the boilerplate is wrong. Action: Change the boilerplate to that used with (e.g.) errno.h. _____________________________________________________________________________ COMMENT Enhancement Request Number 301 Andries.Brouwer@cwi.nl Bug in XBDd5 (locale.h) (rdvk# 304) [] Tue, 6 Feb 2001 04:15:24 +0100 (MET) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 275 Line: 9553 Section: locale.h Problem: Wrong prototype Action: Replace char setlocale by char *setlocale. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 302 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 369) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 287 Line: 10018-10021 Section: omitted Problem: There are instances of "char*". Action: On these lines change any "char*" to "char *". _____________________________________________________________________________ OBJECTION Enhancement Request Number 303 mccann@zk3.dec.com Bug in XBDd5 (AI_NUMERICSERV) (rdvk# 385) [Compaq-JM8] Wed, 14 Feb 2001 14:32:04 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the following text after line 10105: AI_NUMERICSERV Inhibit service name resolution _____________________________________________________________________________ Page: 289 Line: 10099 Section: Problem: AI_NUMERICSERV is missing from . Action: Add the following text after line 10105: AI_NUMERICSERV a non-null service name must be a numeric port string _____________________________________________________________________________ COMMENT Enhancement Request Number 304 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 370) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 291 Line: 10162 Section: omitted Problem: It may be necessary to expose the symbols of (for socklen_t). Action: Add ", " after . _____________________________________________________________________________ OBJECTION Enhancement Request Number 305 donnte@microsoft.com Bug in xbdd5 Integer types/networking (rdvk# 384) [DST-2003] Wed, 14 Feb 2001 11:02:33 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See XBD ERN 76, and Austin/SD2 item 32 _____________________________________________________________________________ Page: 292 Line: 10100-10200 Section: netinet/in.h Problem: I have seen objections from Curtis Smith, Andrew Josey, and others, and have serious concerns with all of them. Given the C99 standard requirement that exact width types are exact width even when violating type and looking at "nearby" bits, it is not possible to simultaneously to meet the requirements of this section, C99, and historical POSIX.1 (which explicitly requires that non-8-bit bytes be supported). I do not believe that any one of these 3 conflicting requirements has clear precedence over the others (and in particular, I do not believe that networking has precedence over the historical .1 in this regard). In particular, the C99 aspect of this problem occurred after the networking standards were written, and at the time the networking standards were written the rule about "no extra bits" could not have been taken into account, so I have to take it that there was no intent to change the more-than-8-bit-byte alternative that was present when the networking standards were written. Action: In order of preference: 1a) Get c99 to change in some way to allow the presence of both non-8-bit bytes and the exact width types in some reasonable way. (There may be several possible solutions to this.) 1b) Figure out how to achieve the desired goals without having to change c99. 2) Change networking to allow conformance. (The lack of response to the continued requests for help in this area from the networking folks makes option 4 particularly interesting.) 3) Drop (strict conformance to) c99, on the grounds that it has requirements inconsistent with our needs. 4) Similarly drop networking. 5) Drop support for bytes of sizes othet than n*8, if that helps. (Dropping support for bytes of size other than exactly 8 is NOT responsive to this objection.) Actions 3, 4, and 5 all violate the scope of this project, and require that the scope be re-approved by our sponsoring bodies. Networking folks: some thoughts on how to achieve alternative 1b. Would an array of bitfields (without padding!) solve the problem? If so, that's not an unreasonable C extension, and I don't see that it would be unreasonable to require that C extension in our standard. We'd then not touch the exact width types, but do what we need with that new type. (The spec would have to be explicit about packing order for such arrays, to avoid implementations choosing to pack them as DCBAHGFE or the like.) Or could the packing be macro-ized so that it's implemented as a simple array on an octet machine, and "magic" on non-octet machines. (Where "magic" is vendor specified.) (This is not thought out, but something like OCTET(object, i) would translate to object[i] on a 8-bit machine, and to some other magic on a machine with a different byte size. (Yes, I envision that the type would be an lvalue.) (The general thrust of my thinking is to somehow move octets out of the normal type space, so it doesn't trip the C rules at all, and let the vendor decide how to map it back into reality. We just need to specify the semantics properly.) _____________________________________________________________________________ COMMENT Enhancement Request Number 306 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 371) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 292 Line: 10185 Section: omitted Problem: It may be necessary to expose the symbols of (for sa_family_t). Action: Add "and " after "". _____________________________________________________________________________ COMMENT Enhancement Request Number 307 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 372) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 292 Line: 10191-10194 Section: omitted Problem: To preserve the style on lines 10203-10207, add comments here respectively: Action: AF_INET Port number. IP address. Padding. _____________________________________________________________________________ OBJECTION Enhancement Request Number 308 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 373) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete XBDd5 p292 line 10914 Add to change history The sin_zero member was removed from the sockaddr_in structure as per The Open Group Base Working Groupo resolution bwg2001-004. **CROSS VOLUME CHANGE** XSHd5 p 905 Change 14212 All fields in socket address structures returned by getaddrinfo ( ) that are not filled in through an explicit argument (for example, sin6_flowinfo and sin_zero) shall be set to zero. to All fields in socket address structures returned by getaddrinfo ( ) that are not filled in through an explicit argument (for example, sin6_flowinfo) shall be set to zero. _____________________________________________________________________________ Page: 292 Line: 10194 Section: omitted Problem: Why specify padding, leave it to the implementation. Action: Delete 10194. _____________________________________________________________________________ OBJECTION Enhancement Request Number 309 curtis.smith@simtrol.com Bug in XBDd5 description (rdvk# 361) {1} Wed, 14 Feb 2001 15:16:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See XBD 76 _____________________________________________________________________________ Page: 292 Line: 10199-10200 Section: Problem: The s6_addr field is defined to be of the type uint8_t which, in effect, makes an unnecessary requirement to support an addressable data type of 8 bits with no padding, but this is an unrealistic restriction given the advent of character sets of greater sizes where it would be logical to make the char datatype larger (e.g., 16 or 32 bits). Furthermore, the reference to "network byte order" is inappropriate, since "network byte order" is defined to refer to storing a quantity in an "int" data type; not an array of uint8_t. Action: Change the data type of s6_addr uint8_t[] to unsigned char[]. Also change the comment "stored in network byte order" to "stored by splitting the 128-bit address into octets stored in descending order of their significance (e.g., high-order octet in s6_addr[0])." _____________________________________________________________________________ OBJECTION Enhancement Request Number 310 ajosey@rdg.opengroup.org Bug in XBDd5 description (rdvk# 363) Wed, 14 Feb 2001 15:52:16 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 292 Line: 10199-10200 Section: {aj.feb14.1} Problem: I have seen objection 1 ,austin-review-l:archive/latest/835 and would object to this change being made without careful consideration and input from those involved in the IPv6 development. This current requirement is drawn from XNS 5.2 and the underlying RFCs and my understanding was that the wording is intentional. Action: Get input from the networking experts, any changes to this need to be compatible with the underlying RFCs and backwards compatible to XNS5.2; if not reject the change in austin-review-l:archive/latest/835 objection {1} from Curtis Smith _____________________________________________________________________________ COMMENT Enhancement Request Number 311 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 374) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 293 Line: 10245,10250 Section: omitted Problem: These lines should be commented. Action: Change "16." to "16 Length of the string form for IP". Change "42." to "42 Length of the string form for IPv6". _____________________________________________________________________________ COMMENT Enhancement Request Number 312 gwc@unisoft.com BUG in XBDd5 sys/types.h (rdvk# 111) {gwc regoff_t} Thu, 1 Feb 2001 19:37:37 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 306 Line: 10700 Section: regex.h Problem: The stated purpose of regoff_t is to hold the largest possible ssize_t and off_t values. These two types are both required to be integer types, so there is no reason not to require regoff_t to be an integer type as well. Note that if this change is considered to be out of scope, it can easily be brought into scope by filing a POSIX interp request. If it is rejected for being out of scope, please give an indication of whether it would be accepted if resubmitted after it has been brought into scope. Action: Change "signed arithmetic type" to "signed integer type". _____________________________________________________________________________ COMMENT Enhancement Request Number 313 drepper@redhat.com Bug in XBDd5 (rdvk# 94) {ud-19} Sat, 27 Jan 2001 05:36:35 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The change could not be made as it is out of scope. _____________________________________________________________________________ Page: 312 Line: 10889 Section: Problem: The header already allows and to be included. After the addition of the sem_timedwait() function this wasn't extended to . Action: Replace line 10889 with , , and . where "and " is XSI shaded. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 314 wollman@lcs.mit.edu Bug in XBDd5 (rdvk# 54) {none} Wed, 24 Jan 2001 01:42:43 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 314 Line: 10981 Section: Problem: The text states ``if the Realtime Signals Extension option is supported''. This paragraph is already shaded RTS, so the quoted qualification is redundant. Action: Delete the redundant text. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 315 Clive D.W. Feather Bug in XBDd5 (rdvk# 106) [CDWF-515] Wed, 31 Jan 2001 11:18:13 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 317 Line: 11079-11080 Section: signal.h Problem: The entire paragraph should be CX marked, not just the name siginfo_t. Action: Make it so. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 316 pete.forman@westerngeco.com BUG in XBDd5 (rdvk# 4) [PWF20001220/3] Wed, 20 Dec 2000 14:10:45 +0000 (GMT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 322 Line: 11278 Section: Problem: Declaration of posix_spawn() has been partially deleted and wrongly indented. XBDd3 was complete though wrongly indented. XBDd4 should have introduced some restrict modifiers. The replacement text offered here is derived from XSHd5 page 1371 lines 28501-28504 section posix_spawn(). Action: change "const posix_spawnattr_t *, char *const [], char *const []);" to "int posix_spawn(pid_t *restrict, const char *restrict, const posix_spawn_file_actions_t *, const posix_spawnattr_t *restrict, char *const [restrict], char *const [restrict]);" [Ed recommendation: Accept as marked. Delete the line at 11278, posix_spawn() now appears alphabetically on the preceeding page, this was dangling text that should be removed] _____________________________________________________________________________ OBJECTION Enhancement Request Number 317 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 302) [DST-278] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 323 Line: 11332 Section: stdarg.h Problem: We have the right term, use it. Action: function is indeterminate -> function is unspecified _____________________________________________________________________________ OBJECTION Enhancement Request Number 318 baker@dad.cs.fsu.edu Bug in XBDd5 stddef.h (rdvk# 49) {QLUE 100101001} Thu, 11 Jan 2001 08:52:55 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_322 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 326 Line: 11424-11430 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. The guarantee in question exists in the current standard and should not have been removed by accident. Action: Make the changes proposed in XBDd4 ERN237 (See Geoff Clare's XBDd5 aardvark for the new page and line numbers.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 319 nmm1@cus.cam.ac.uk BUG in XBDd5 stddef.h (rdvk# 50) Sun, 14 Jan 2001 17:50:42 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_322 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 326 Line: 11424-11430 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. The following is a opy of something that I posted to the C standard reflector, with a couple of clarifications and some paragraphs irrelevant to POSIX removed: I took a copy of gcc and hacked it around enough to produce diagnostics for some of the problem cases, where C99 introduces a quiet change over C89 in the area of 'long' and 'long long'. However, this hack has the following properties: 1) It flags only some traps. 2) It produces a large number of false positives, which needed looking at by hand (in the table below, this has been done). 3) It requires header hacks, and produces broken code. I then ran it on a range of widely-used and important public-domain codes, taken from the Debian 1.3.1 CD-ROM set. Many of these are effectively the same codes that are shipped with commercial systems, and others are relied on heavily by many sites. Most of the codes used "long" to hold object and file positions, or as a way of printing an unknown integer type. The ones that I have marked as "Yes" will almost certainly invoke undefined behaviour if faced with a C99 compiler where ptrdiff_t is longer than "long", and probably will even if only off_t is. The ones that I have marked "Maybe" could well have checks to prevent this, or were too spaghettified to investigate. Only 4 had any reference to "long long" whatsoever, and it was in a single non-default #if'd out section in 3 of them; one of those defined a symbol that was never referred to, another was solely for Irix 6 file positions, and the last could trivially have been replaced by double. The ONLY program that either had any reference to "long long" by default, or used it seriously, was gcc itself. Loss of data printf fails Uses long long ------------ ------------ -------------- apache Yes Yes No bison No No No bash Maybe Yes No cpio Yes No Effectively not csh Yes No No diff Maybe No No elm Build process failed No exim Yes No No fileutils Yes No Effectively not findutils Yes Yes No flex No No No gawk Yes Yes No gcc Build process failed Yes gnuplot Maybe No No gzip Yes No No icon Yes No No inn Build process failed No nvi Maybe Yes No pari Maybe No No perl Build process failed Effectively not sendmail Yes Yes For Irix 6 trn Maybe No No wu-ftpd No Yes No zip Yes Yes No I already have files of larger than 4 GB but, far worse, I need to allow users to handle such files just as soon as I can configure my systems to do so; and, yes, I shall be exporting them across systems :-( Within 12 months (i.e. before there is ANY chance of C99 becoming a reality on the ground), I shall have users running single processes with more than 4 GB data objects. I already have users who run jobs with more than 4 GB of RAM. [ These changes are in progress, as I said they would be, though more slowly than I hoped. ] I just don't have to the time to check that every vendor has compiled his system utilities with 64-bit longs or fixed the bugs caused by not doing so, even if I have access to all the relevant systems. But I am unquestionably going to be called in to sort out the file corruptions caused by not doing so. And the above investigations indicate that 64-bit size_t on a system with 32-bit long is going to be a disaster. Most other people may not have these problems today, but they are assuredly going to be hit by them before C99 becomes official, vendors deliver working C99 compilers, and the utilities are modified accordingly. For many people, this changeover will be much worse than the Year 2000 fiasco if size_t is allowed to exceed long. [ I have seen several bugs caused by off_t exceeding long, and that is TRIVIAL by comparison. ] The following was NOT posted to the C reflector, but is relevant to POSIX: Independently of the above, I had already needed to compile quite a few those for Irix, and I did so in 64-bit mode (which is and was the default on the systems I manage). As far as I can remember, the list was apache, bash, fileutils, findutils, gawk, gzip, wu-ftpd and zip. I am pretty certain that NONE of them had ANY 64-bit system in their supported list at the time, I remember that I had to back off to 32-bit mode ONLY for apache and bash, and think that only wu-ftpd needed ANY source changes to move from 32-bit to 64-bit longs. Other evidence confirming this is that most of them work perfectly on machines with 64-bit longs (e.g. Alphas). An inspection of the source would indicate how difficult that migration was, but I am pretty sure that it was more-or-less trivial in most cases. It is NOT true that most programs have serious dependencies on long being exactly 32 bits, though it is true that networking programs often have a few, localised dependencies. Action: Make the changes proposed in XBDd4 ERN237. (See Geoff Clare's XBDd5 aardvark for the new page and line numbers.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 320 eggert@twinsun.com Bug in XBDd5 stddef.h (rdvk# 11) {eggert-2001-01-05-20:34:02} Fri, 5 Jan 2001 20:39:37 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_322 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 326 Line: 11424 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. I agree with Geoff Clare's assessment of the problem. The only technical objection to ERN237 was that it constrains future implementations. But these constraints are necessary: many of the programs that I help maintain for the GNU project depend on them. My programs can deal with off_t being longer than long, but they will break if size_t is longer than long. It is not feasible to rewrite these programs. It would take a lot of work to manually inspect them for problems, and the programs must be portable to older C implementations so simplistic solutions like "use %j" are not possible. If ERN237 continues to be rejected, I plan to ignore this part of the standard, and behave as if ERN237 were accepted. The GNU coding standards recommend this course of action already; please see its "Portability between CPUs" section, in: http://www.gnu.org/prep/standards_27.html#SEC27 (2000-12-02) Action: Make the changes proposed in XBDd4 ERN237. (See Geoff Clare's XBDd5 aardvark for the new page and line numbers.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 321 evought@qlue.com Bug in XBDd5 stddef.h (rdvk# 48) {QLUE 100101001} Thu, 11 Jan 2001 00:39:13 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_322 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 326 Line: 11424-11430 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. The guarantee in question exists in the current standard and should not have been removed by accident. Action: Make the changes proposed in XBDd4 ERN237 (See Geoff Clare's XBDd5 aardvark for the new page and line numbers.) _______________________________________________________________________________ OBJECTION Enhancement Request Number 322 gwc@unisoft.com BUG in XBDd5 (preserve integral types) (rdvk# 12) {gwc preserve integral types} Fri, 5 Jan 2001 18:12:06 +0000 _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (updated 26.3.2001) XCU c99 (XBD ERN 322) page 2428 insert after line 8319 Table 4-4 HERE All implementations shall support one or more environments where the widths of the following types are no greater than the width of type long: blksize_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t, speed_t, ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t, wint_t The executable files created when these environments are selected shall be in a proper format for execution by the exec family of functions. Each environment may be one of the ones in Table 4-4, or it may be another environment. The names for the environments that meet this requirement shall be output by a getconf command using the _POSIX_V6_WIDTH_RESTRICTED_ENVS argument. If more than one environment meets the requirement, the names of all such environments shall be output on separate lines. Any of these names can then be used in a subsequent getconf command to obtain the flags specific to that environment with the following suffixes added as appropriate: _CFLAGS to get the C compiler flags _LDFLAGS to get the linker/loader flags _LIBS to get the libraries This requirement may be removed in a future version of IEEE Std .... page 2431 after line 8430 Example 4: The following example shows how an application can use a programming environment where the widths of the following types: blksize_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t, speed_t, ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t, wint_t are no greater than the width of type long: # First choose one of the listed environments ... # ... if there are no additional constraints, the first one will do: CENV=$(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS | head -n 1) # ... or, if an environment that supports large files is preferred, # look for names that contain "OFF64" or "OFFBIG". (This chooses # the last one in the list if none match): for CENV in $(getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS) do case $CENV in *OFF64*|*OFFBIG*) break ;; esac done # The chosen environment name can now be used like this: c99 $(getconf ${CENV}_CFLAGS) -D_POSIX_C_SOURCE=200xmmL \ $(getconf ${CENV}_LDFLAGS) foo.c -o foo \ $(getconf ${CENV}_LIBS) (the xmmL to be filled in). XCU getconf page 2693, add after line 18400: POSIX_V6_WIDTH_RESTRICTED_ENVS _CS_POSIX_V6_WIDTH_RESTRICTED_ENVS XBD page 298, add after line 10371: The implementation shall support one or more programming environments in which the width of nfds_t is no greater than the width of type long. The names of these programming environments can be obtained using the confstr() function or the getconf utility. XBD page 326, add after line 11430: The implementation shall support one or more programming environments in which the widths of ptrdiff_t, size_t and wchar_t are no greater than the width of type long. The names of these programming environments can be obtained using the confstr() function or the getconf utility. XBD page 381, add after line 13263: The implementation shall support one or more programming environments in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t and useconds_t are no greater than the width of type long. The names of these programming environments can be obtained using the confstr() function or the getconf utility. XBD page 392, add after line 13566: The implementation shall support one or more programming environments in which the widths of cc_t, speed_t and tcflag_t are no greater than the width of type long. The names of these programming environments can be obtained using the confstr() function or the getconf utility. XBD page 422, add after line 14691: _CS_V6_WIDTH_RESTRICTED_ENVS This value is a separated list of names of programming environments supported by the implementation in which the widths of the blksize_t, cc_t, mode_t, nfds_t, pid_t, ptrdiff_t, size_t, speed_t, ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t, and wint_t types are no greater than the width of type long. XBD page 436, add after line 15278: The implementation shall support one or more programming environments in which the width of wint_t is no greater than the width of type long. The names of these programming environments can be obtained using the confstr() function or the getconf utility. XSH confstr page 692, add after line 7475: _CS_POSIX_V6_WIDTH_RESTRICTED_ENVS XSH section 2.3 page 498, replace lines 1289-1295 with: [EOVERFLOW] Value too large to be stored in data type. An operation was attempted which would generate a value that is outside the range of values that can be represented in the relevant data type or that are allowed for a given data item. XRAT page 3381, add after Line 3271: EOVERFLOW: Most of the uses of this error code are related to large file support. Typically these cases occur on systems which support multiple programming environments with different sizes for off_t, but they may also occur in connection with remote file systems. In addition, when different programming environments have different widths for types such as int and uid_t, several functions may encounter a condition where a value in a particular environment is too wide to be represented. In that case, this error should be raised. For example, suppose the currently running process has 64-bit 'int', and file descriptor 9223372036854775807 is open and does not have the close-on-exec flag set. If the process then uses execl() to exec a file compiled in a programming environment with 32-bit 'int', the call to execl() can fail with errno set to EOVERFLOW. A similar failure can occur with execl() if any of the user IDs or any of the group IDs to be assigned to the new process image are out of range for the executed file's programming environment. Note however, that this condition cannot occur for functions that are explicitly described as always being successful, such as getpid(). _______________________________________________________________________________ Page: 326 Line: 11424-11430 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. It seems to me that the views of the small number of people at the plenary were not representative of the views of the group as a whole on this particular issue. During the lengthy discussions on the austin-group email reflector there was a great deal of support for this proposal. (Of those who participated in the discussion, the vast majority were supporters.) I also believe that some people have misunderstood the implications of the proposal, and that the decision at the plenary may have been swayed by this. So before I examine the reasons given for rejection, I would like to make sure one thing is clear to everybody: This proposal seeks to _preserve_ a feature of the current POSIX and UNIX standards on which virtually every non-trivial existing application relies. The proposed restrictions are not really "new" restrictions, in that they do not prevent any implementations (existing or future) from being compliant with the new POSIX and UNIX standards that are not already non-compliant with the current POSIX and UNIX standards. The feature in question is that all size_t, ssize_t, pid_t, ptrdiff_t, wchar_t and wint_t values can fit in a (signed or unsigned, as appropriate) long int. (And the same for a few other, less used, types.) The proposal seeks to preserve this feature by adding a requirement that these types must be no wider than (signed or unsigned) long int. In the draft 4 aardvark report, the reasons given for rejection were: 1. "Adding additional restrictions to the types limits future extensions" Again, these are not really _additional_ restrictions, but if you look at it from the other direction, then this is a valid point - i.e. keeping the range of types allowed for size_t etc. the same as they are in the current POSIX and UNIX standards does mean the choices available to implementors are more limited than if the range of types is widened (as in drafts 4 and 5). Specifically, it affects the choice of widths that implementors have for long int. E.g. if size_t and ptrdiff_t are 64 bits, then the new standard without the proposed restrictions would allow a minimum width for long int of 32 bits, whereas the new standard with the proposed restrictions would limit the choice of widths to 64 bits or greater (the same as for the current POSIX and UNIX standards). This is not really much of a limitation. For 64-bit architectures, 64-bit long int is already the de-facto standard. For 32-bit architectures that can address more than 4GB of memory, the implementor can choose between having size_t and long int both be 32 bits and having them both be 64 bits. Choosing 32-bit size_t means there is a limit on the size of single objects, but the address space of a process can still be larger than 4GB. Choosing 64-bit long int allows larger single objects, but may affect performance. However, applications for which performance is an issue can use int32_fast_t instead of long int where appropriate. If anyone really needs 64-bit size_t with 32-bit long int it is only going to be a small number of specialist applications. These could be catered for by providing an additional non-compliant compilation environment, as was done when people started to need to support large files on 32-bit systems. I don't believe there are a sufficient number of such applications to justify accommodating the compilation environment they need by relaxing the standard, given the severe problems it causes for virtually all other existing applications. 2. "some of this is a quality of implementation issue" Calling it a quality of implementation issue presupposes that the proposed restrictions will not be included in the new standard. It will certainly become a quality of implementation issue in that case, but only after the fact. Application writers will then fall into three groups depending on their attitude towards "poor quality" implementations: a. If they need their applications to work on the poor quality implementations (or possible future poor quality implementations), they will have to expend an enormous amount of effort to make them work. (Effort that will have been wasted if no such implementations are produced.) b. If they don't need their applications to work on the poor quality implementations, and they know about the problem, they will take steps to prevent their applications from being compiled on the poor quality implementations. c. If they don't know about the problem, their applications will very probably misbehave (perhaps silently corrupting data) if they are ever installed on poor quality implementations. I don't see this as a satisfactory state of affairs. I think it is imperative that the new standard contains restrictions that prevent it from happening. 3. "existing practise may already be at odds with the proposal" This one surprised me, as there had been no mention of it in the discussions on the reflector. After enquiring who had made the suggestion of existing practice at the plenary, I entered a discussion of the matter with him. It turns out that what he had in mind was 32-bit architectures which support a greater than 4GB address range. These have already been discussed in point 1 above (but as potential future implementations, not as existing implementations). I don't believe these architectures constitute "contrary existing practice", as the minutes of the plenary describe it. To qualify as contrary existing practice there would have to be an existing implementation that would be compliant with the new standard if the proposed restrictions are rejected and non-compliant if they are accepted. I am not aware of any such implementation. Note in particular that having a compilation environment where long int is 32 bits and size_t is 64 bits does not necessarily mean that an implementation does not comply. In order to comply it just needs to support a second compilation environment that meets the requirements of the standard. In addition to the reasons stated in the draft 4 aardvark report, the minutes of the plenary also contain the following statements: 4. "Reject, use %j modifier" Stating this as a "solution" in such simple terms represents a failure to recognise the magnitude of the problem. Changing existing applications to use %j (and similar changes for other code that is affected besides printf() calls) would require a huge amount of effort. This is because there is no way to automate the changes - the best that can be done it to use a tool which identifies the places where potential problems exist in the code and then examine each one closely. Many of these will turn out to be false positives, but they still require time to analyse. If the changes could be automated this would make the problem much less serious, but they can't. The nature of the problem is very similar to Y2K, except that this one is *bigger* than Y2K, because code related to size_t occurs more often than code related to dates. 5. "This restriction was previously lifted (by LFS)" This is simply untrue. LFS extended the range of types allowed for off_t and some other file-size-related defined types such as blkcnt_t. Those types are not included in the restrictions being proposed. 6. "Apps that assume 32 bit architectures are already broken in the presence of 64 bit ones" This is true, but I don't see how it is relevant. The applications that are affected by this issue are ones which assume that all size_t values will fit in an unsigned long int. This assumption is valid for all existing POSIX/UNIX conformant implementations with 64 bit architectures, because they have 64-bit size_t and 64-bit long int. Here is a summary of the situation as I see it: Several strong arguments have been given supporting the proposal. Of the arguments against it, all but one do not stand up to scrutiny. Even the one that does stand up (that restricting the range of types allowed is a limitation on future implementations) is not so much an argument against the proposal as a simple observation. The whole point of the proposed restriction is to limit future implementations. This limitation is absolutely necessary, for the sake of portability of existing applications. It could even be argued that it benefits implementors, because it prevents them from making a costly mistake. If any implementations with size_t wider than long int are ever produced, they would soon be tainted with a reputation for porting difficulty and misbehaving applications. Action: In the definition of ptrdiff_t on line 11424 change "Signed integer type" to "Signed integer type no wider than long int". In the definition of wchar_t on line 11425 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 11430 change "Unsigned integer type" to "Unsigned integer type no wider than unsigned long int". Related changes on other pages: page 298 line 10371 section poll.h objection { nfds_t } Change "unsigned integer type" to "unsigned integer type no wider than unsigned long int". page 381 line 13258 section sys/types.h objection { size_t } Change "unsigned integer type" to "unsigned integer type no wider than unsigned long int". page 381 line 13259 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 381 line 13261 section sys/types.h objection { useconds_t } Change "unsigned integer type capable" to "unsigned integer type, no wider than unsigned long int, capable". page 381 line 13262 section sys/types.h objection { suseconds_t } Change "signed integer type capable" to "signed integer type, no wider than long int, capable". page 392 line 13566 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 436 line 15269 section wchar.h objection { wint_t } Change "integer type capable" to "integer type, no wider than long int, capable". _____________________________________________________________________________ OBJECTION Enhancement Request Number 323 Clive D.W. Feather Bug in XBDd5 (rdvk# 16) Wed, 10 Jan 2001 11:41:47 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_322 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 326 Line: 11424-11430 Section: stddef.h Problem: XBDd4 ERN237 should not have been rejected. Action: Make the changes proposed in XBDd4 ERN237. (See Geoff Clare's XBDd5 aardvark for the new page and line numbers.) _____________________________________________________________________________ COMMENT Enhancement Request Number 324 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 91) [CDWF-510] Fri, 26 Jan 2001 09:17:10 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to rationale on p333 As a consequence of adding int8_t the following are true: - a byte is exactly 8 bits; - CHAR_BIT has the value 8, SCHAR_MAX has the value 127, SCHAR_MIN has the value -127 or -128, and UCHAR_MAX has the value 255; _____________________________________________________________________________ Page: 328 Line: 11483-11489 Section: stdint.h Problem: It may not be immediately obvious that requiring the int8_t type has implications for elsewhere. Action: Add a CX-shaded note saying something like: The requirement for these types to be provided means that: - a byte is exactly 8 bits; - CHAR_BIT has the value 8, SCHAR_MAX has the value 127, SCHAR_MIN has the value -127 or -128, and UCHAR_MAX has the value 255; - at least certain types are two's complement. _____________________________________________________________________________ OBJECTION Enhancement Request Number 325 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 90) [CDWF-509] Fri, 26 Jan 2001 09:17:10 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 328 Line: 11490-11504 Section: stdint.h Problem: There is a fourth case that hasn't been considered. C99 requires the 64 bit type names to be defined if there are types that meet the requirement. This remains the case no matter what options are selected when building the implementation. Action: After line 11500 add a fourth bullet item: if any of the standard integer types or any of the integer types declared in this or any other header have the appropriate property (width 64, two's complement, no padding bits) Remove the CX shading from lines 11490, 11501-11504; the new text is also unshaded. _____________________________________________________________________________ COMMENT Enhancement Request Number 326 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 89) [CDWF-508] Fri, 26 Jan 2001 09:17:10 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 328 Line: 11505 Section: stdint.h Problem: The wording could be read as making all other types in this header optional. It's also not the wording used elsewhere. Action: Change it to: "All other types of this form are optional." ^^^^^^^^^^^^ (text added) _____________________________________________________________________________ OBJECTION Enhancement Request Number 327 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 307) [DST-2000] Tue, 6 Feb 2001 22:07:05 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Withdrawn by originator _____________________________________________________________________________ Page: 328 Line: 11517 Section: inttypes.h Problem: For the exact width types, the 64 bit types are not required unless needed by some option (see 11490-11503). However, the 64 bit "least" and "fast" types are required on all implementations, as far as I can tell. I don't see any reason to not require the exact type, while requiring the least and fast versions. Action: Apply the same criteria that determined if the exact width 64 bit types are needed to the least and fast versions (and if there were any I missed). (A simpler statement of that might be "if the 64 bit exact width types are required, then the following are required as well", to avoid repeating the fairly long test 3 times (and having it get out of phase sooner or later). _____________________________________________________________________________ OBJECTION Enhancement Request Number 328 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 88) [CDWF-507] Fri, 26 Jan 2001 09:17:10 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 330 Line: 11587 Section: stdint.h Problem: N-1 The minimum limit for INT_LEASTN_MAX is given as 2 . This is wrong. Action: N-1 Change the minimum to 2 - 1. _____________________________________________________________________________ COMMENT Enhancement Request Number 329 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 387) [DWC-jf-1] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 337 Line: 11844 Section: stdio.h Problem: (Change History) The function getw() has been removed. It was LEGACY in SUSv2. This should be refected in the change history. Action: Add getw() to the list of functions removed due to them being LEGACY on P337, L11844. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 330 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 388) [DWC-jf-2] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 337 Line: 11849 Section: stdio.h Problem: (Change History) The text on P337, L11849 duplicates a subset of what is specified on P337, L11848. There are lots of functions besides fseeko() and ftello() that are marked CX. Either the entire list of extensions should be noted, or the explicit reference to fseeko() and ftello() should be dropped. Action: Delete P337, L11849. ------------------------------------------------------------------------------ _____________________________________________________________________________ COMMENT Enhancement Request Number 331 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 389) [DWC-jf-3] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 341 Line: 11988 Section: stdlib.h Problem: (Change History) The change history should note LEGACY functions that have been removed. Action: Add a new paragraph after P341, L11988: The ttyslot() and valloc() are removed as they were previously marked LEGACY. List functions ttyslot() and valloc() were LEGACY in the previous revision and have been removed. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 332 wollman@lcs.mit.edu Bug in XBDd5 strings.h (rdvk# 1) {GAW-2} Fri, 15 Dec 2000 16:21:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Out of scope _____________________________________________________________________________ Page: 344 Line: 12065 Section: strings.h Problem: The definition of the strings.h header file does not permit the common and historic practice of defining some or all symbols from the string.h header file. Also, two of the three non-legacy functions would be permitted by the existing namespace rules to be defined in string.h, to wit, strcasecmp() and strncasecmp(), and ought to be available from that header. Action: Before line 12065, insert: Inclusion of the header may also make visible all symbols from . Also, move line 12062 to page 342 after line 12009 (shaded XSI), and move line 12063 to page 342 after line 12018 (shaded XSI). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 333 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 383) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 345 Line: 12088 Section: omitted Problem: Only the strbuf structyre fields have comments. Action: Add the following comment to the struct members: Priority band. Flushing type. The control portion of the message. The data portion of the message. RS_HIPRI or 0. The control portion of the message. The data portion of the message. RS_HIPRI or 0. File descriptor of the other STREAM. Relative location of the stored value. Ioctl command. Timeout for response. Length of data. Pointer to buffer. Received file descriptor. Uid of sender. Gid of sender. Number of STREAMS module names. STREAMS module names. A STREAMS module name. _____________________________________________________________________________ COMMENT Enhancement Request Number 334 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 375) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 345 Line: 12119-12120 Section: omitted Problem: Referencing XNS5.2 seems bad here. Action: Import the definition from in XNS5.2 to this location. [Ed recommendation: Accept as marked. Replace 12119-12120 with The header shall define t_scalar_t and t_uscalar_t types respectively as signed and unsigned opaque integral types of equal length of at least 32 bits. ] _____________________________________________________________________________ COMMENT Enhancement Request Number 335 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 376) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 346-348 Line: 12129-12227 Section: omitted Problem: The definitions of the I_ ioctls foreshadows the real information in ioctl(), and wrongly states several facts. Here we should just list the defines and a cursory comment, break out the subdefinitions and rely on only one normative set of definitions. Action: Reduce the section to: I_PUSH Push a STREAMS module. I_POP Pop a STREAMS module. I_LOOK Get the top module name. I_FLUSH Flush a STREAM. I_FLUSHBAND Flush one band of a STREAM. I_SETSIG Ask for notification signals. I_GETSIG Retrieve current notification signals. I_FIND Look for a STREAMS module. I_PEEK Peek at the top message on a STREAM. I_SRDOPT Set the read mode. I_GRDOPT Get the read mode. I_NREAD Size the top message. I_FDINSERT Send implementation defined information about another STREAM. I_STR Send a STREAMS ioctl. I_SWOPT Set the write mode. I_GWOPT Get the write mode. I_SENDFD Pass a file descriptor through a STREAMS pipe. I_RECVFD Get a file descriptor sent via I_SENDFD. I_LIST Get all the module names on a STREAM. I_ATMARK Is the top message "marked"? I_CKBAND See if any messages exist in a band. I_GETBAND Get the band of the top message on a STREAM. I_CANPUT Is a band writable? I_SETCLTIME Set close time delay. I_GETCLTIME Get close time delay. I_LINK Connect two STREAMS. I_UNLINK Disconnect two STREAMS. I_PLINK Persistenly connect two STREAMS. I_PUNLINK Dismantle a persistent STREAMS link. Put lines 12133-12136 here starting from "At least" and changing "as the arg argument" to "with I_LOOK". Put lines 12138-12142 here starting from "At least" and changing "as the arg argument" to "with I_FLUSH". Put lines 12146-12170 here changing "possible values for arg when I_SETSIG is specified" to "macros for use with I_SETSIG". Put lines 12176-12178 here starting from "At least" and changing "as the arg argument" to "with I_PEEK". Put lines 12179-12189 here changing "possible values for arg when I_SETSIG is specified" to "macros for use with I_SRDOPT". Put lines 12197-12200 here changing "possible values for arg when I_SETSIG is specified" to "macros for use with I_SWOPT". Put lines 12209-12212 here changing "possible values for arg when I_SETSIG is specified" to "macros for use with I_ATMARK". Put lines 12222-12225 here making the equivalent change as above. _____________________________________________________________________________ COMMENT Enhancement Request Number 336 donnte@microsoft.com Bug in xbdd5 (rdvk# 45) [DST-29] Wed, 10 Jan 2001 22:24:23 -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 359 Line: 12530 Section: sys/select.h Problem: The phrase "for use with an ISO C standard compiler" here (and elsewhere) appears to be a leftover from the (unlamented) demise of common-usage C. It seems to add nothing to say this now that ONLY ISO C compilers are under discussion. Action: Remove "for use with an ISO C standard compiler" here (and in all other ocurrences, which are easier to find in the document source than the pdf). [Ed recommendation: Accept This is a global change to the headers, leaving just the requirement that prototypes be provided.] _____________________________________________________________________________ COMMENT Enhancement Request Number 337 wollman@lcs.mit.edu Bug in XBDd5 (rdvk# 10) {GAW-3} Thu, 4 Jan 2001 03:46:34 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (cross volume change) add to XSHd5 p 488 line 856 insert fd_,fds_, FD_ Change on XBD p359 l12531 from The header shall define the fd_set type as a structure that includes at least the following member: long fds_bits[] Bit mask for open file descriptions. to The header shall define the fd_set type as a structure. Add to change history The requirement for the fd_set structure to have a member fds_bits has been removed as per The Open Group Base Working Group resolution bwg2001-005. _____________________________________________________________________________ Page: 359 Line: 12531-12533 Section: Problem: The specification requires a particular implementation for the internals of the fd_set type. This is an implementation detail which should not be standardized, and in any case the meaning and use of the specified member is not defined anywhere in the standard nor is it mentioned in the rationale. All necessary operations on the fd_set type are defined in the FD_* macros and the C assignment operator. Action: Replace the indicated lines with: The header shall define the fd_set type as a scalar or non-array aggregate type. Make the same change at XBD page 376 lines 13088-13090. If this change is made, fds_ should be deleted from the namespace reservation table at XSI page 488 line 862. _____________________________________________________________________________ COMMENT Enhancement Request Number 338 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 377) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 359 Line: 12533 Section: omitted Problem: "long" seems a bad type here. Action: Change "long" to "int". [Ed recommendation: REJECT This would be a change from earlier issues, so I am inclined to recommend rejection] _____________________________________________________________________________ COMMENT Enhancement Request Number 339 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 378) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation for rationale regarding existing practise _____________________________________________________________________________ Page: 359 Line: 12554 Section: omitted Problem: For parity with pselect() should the struct timeval here be const? Action: Insert "const" before "struct timeval". [Ed recommendation: None This question is (according to the line number reference) referring to the select() interface. The definition of select() at XSHd6 page 1479, line 31155-6, makes it quite clear: Upon successful completion, the select( ) function may modify the object pointed to by the timeout argument. This is a long-standing documented possible behavior of this interface; it was documented thus in the original implementation (4.2BSD) and should not be changed fifteen years after the fact. Applications should be encouraged to transition to the pselect() interface if they do not wish to recompute their timeouts before every call to select().] _____________________________________________________________________________ COMMENT Enhancement Request Number 340 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 379) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 365 Line: 12668-12669 Section: omitted Problem: opaque doesn't mean anything useful. Action: Delete "opaque" and change "length" to "width". [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 341 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 98) [CDWF-511] Wed, 31 Jan 2001 09:52:05 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 365 Line: 12668 Section: sys/socket.h Problem: The type socklen_t is described as "opaque". Since it is clear from other parts of the text that it holds the size of a buffer, in bytes, this is at best a misleading term. Action: Delete the word "opaque". [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 342 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 99) [CDWF-512] Wed, 31 Jan 2001 09:52:05 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 365 Line: 12669 Section: sys/socket.h Problem: The term "length", as applied to an integer type, is meaningless. The standard term for this is "width". Action: Change "length of at least 32 bits" to "width of at least 32 bits". [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 343 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 100) [CDWF-513] Wed, 31 Jan 2001 09:52:05 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: For the first part (for the second the term is thought to be well understood) _____________________________________________________________________________ Page: 365 Line: 12699 Section: sys/socket.h Problem: The term "value=result" should probably be "value-result". Action: Make it so. Comment: This is the only use of the term (with hyphen or equals) in the PDF version. Does it need defining or are we happy with it ? _____________________________________________________________________________ COMMENT Enhancement Request Number 344 drepper@redhat.com Bug in XBDd5 (rdvk# 93) {ud-21} Sat, 27 Jan 2001 20:47:34 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 365 Line: 12701 Section: Problem: The man page currently contains: The iovec structure shall be defined through typedef as described in . But iovec is no typedef. Action: Remove "through typedef" from line 12701. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 345 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 380) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Its not in the base documents and the name can be used in the namespace without this reservation. _____________________________________________________________________________ Page: 366 Line: 12740 Section: omitted Problem: SOCK_RDM has a long history of at least being defined. Action: Add: SOCK_RDM Reliably delivered message socket. _____________________________________________________________________________ COMMENT Enhancement Request Number 346 drepper@redhat.com Bug in XBDd5 (rdvk# 92) {ud-22} Sat, 27 Jan 2001 21:09:28 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 12804 Section: Problem: The socketpair() function's prototype is currently int socketpair(int, int, int, int); This is wrong, see XSH. Action: Replace line 12804 with int socketpair(int, int, int, int[2]); [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 347 mccann@zk3.dec.com Bug in XBDd5 (rdvk# 386) [Compaq-JM4] Wed, 14 Feb 2001 14:22:46 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 368 Line: 12804 Section: Problem: The fourth argument in the socketpair() prototype is incorrect, it is written as type 'int' but is actually a pointer to an array of 2 'int's. Action: Replace line 12804 with "int socketpair(int, int, int, int *);" or "int socketpair(int, int, int, int [2]);" [Ed recommendation: Accept as marked, option 2] _____________________________________________________________________________ OBJECTION Enhancement Request Number 348 Clive D.W. Feather Bug in XBDd5 stdint.h (rdvk# 101) [CDWF-514] Wed, 31 Jan 2001 09:52:05 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_349 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 12807-12808 Section: sys/socket.h Problem: 32 Not all integer types with width 32 bits can store the value 2 - 1. In particular, a signed 32 bit type has width 32 bits, but can't store this value. Action: Any one of: (1) Change the superscript 32 to 31. (2) On page 365 line 12668, change "integer type" to "unsigned integer type". (3) Change page 365 line 12668-6 to require 32 bits excluding sign. In C99 this would be "precision of at least 32 bits", but that term isn't defined in POSIX. Perhaps: 32 "an integer type capable of holding the value 2 - 1;". Given the use of socklen_t, (2) seems most sensible. _____________________________________________________________________________ COMMENT Enhancement Request Number 349 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 381) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 12808 Section: omitted Problem: A 32-bit integer can only guarantee to represent 2**31-1. Action: Change 32 to 31. _____________________________________________________________________________ COMMENT Enhancement Request Number 350 adjg@catullus.eng.sun.com Bugs in XBD Draft 6. (rdvk# 382) [] Wed, 14 Feb 2001 13:39:42 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 12815-12856 Section: omitted Problem: The example is confusing when first read, and then explained. Should be the other way around. Action: Delete line 12815. Move lines 12845-12856 to 12815 changing "above" to "below". In line 12847 change ", sockaddr_in" to "and sockaddr_in". On line 12847 insert ", at least," before "sockaddr_in6". _____________________________________________________________________________ COMMENT Enhancement Request Number 351 ajosey@opengroup.org Bug in XBDd5 sys/time.h (rdvk# 13) {aj.systime.h.jan8} Mon, 8 Jan 2001 11:58:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace 13090 with The fd_set type shall be defined as described in . Replace 13097-13110 with The following shall be defined as described in : FD_CLR() FD_ISSET() FD_SET() FD_ZERO() FD_SETSIZE _____________________________________________________________________________ Page: 376 Line: 13097 Section: sys/time.h Problem: The text at 13097-13110 is a repeat of text in and would be better restated by reference. Action: Replace 13097-13110 with The following are declared as described in : FD_CLR() FD_ISSET() FD_SET() FD_ZERO() FD_SETSIZE [Ed recommendation: None depends on discussion on whether "shall be defined as described" in headers, and then "are->shall be" ?] _____________________________________________________________________________ COMMENT Enhancement Request Number 352 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 390) [DWC-jf-4] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 376 Line: 13114 Section: sys/time.h Problem: (Restrict Keyword) The restrict keyword use in the prototype of gettimeofday() doesn't match the synopsis on P1052. Action: Change: int gettimeofday(struct timeval *, void *restrict); on P376, L13114 to: int gettimeofday(struct timeval *restrict, void *restrict); Add gettimeofday() to the list in the change history on P377, L13136. ------------------------------------------------------------------------------ _____________________________________________________________________________ EDITORIAL Enhancement Request Number 353 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 391) [DWC-jf-5] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 377 Line: 13138 Section: sys/time.h Problem: ( change history) Typo. Action: Change "" on P377, L13138 to "". [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 354 ajosey@opengroup.org Bug in XBDd5 sys/time.h (rdvk# 14) {aj.jan8.1} Mon, 8 Jan 2001 11:58:26 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 377 Line: 13138 Section: sys/time.h Problem: Missing change history Action: Add to CH The utimes() function is marked legacy. [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 355 pete.forman@westerngeco.com BUG in XBDd5 (rdvk# 5) [PWF20001220/4] Wed, 20 Dec 2000 14:10:45 +0000 (GMT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 377 Line: 13138 Section: Problem: Typo. Action: Change "" to "" [Ed recommendation: Accept (this is change history)] _____________________________________________________________________________ OBJECTION Enhancement Request Number 356 IEEE Balloter BUG in P1003.1/D5 Rev. Recirc. (rdvk# 326) [j.isaak@computer.org] Tue, 13 Feb 2001 13:44:39 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_4 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 380 Line: 13233 Section: 13.1 Problem: The response to my objection relating to the range of UID's required by the standard is incorrect. First - what I have requested is the establishing of a minimum value allowed for the uid_t in sys/types.h and assurance that conforming systems can set this value. This is within scope, and must be treated as an objection within scope. Second - this is directly tied to an early request for interpretation of the standard, from NIST, related to the range of UID values that must be permitted, and a defined way to set these values in POSIX conformance testing. As such it is not a new 'problem' but on of the first raised with respect to 1003.1 Beyond the testing/conformance issue, I have subsequently talked with entities (government agencies and universities) who wanted to have unique UID's established for very large numbers of users (often across a number of conforming systems) which is the incentive for pushing this value higher than one of the traditional values of 16K .... although as indicated in my objection, 16K would be acceptable in repsonse to my objection. (I realize that any signficant change from the installed base of major UNIX vendors would raise concerns by members of The Open Group, so I've tried to focus my request in a space where most, if not all Open Group members would find 'no change' in their existing documentation or implementations.) I belive that the appropriate profiling is not to include this in a profile, but make this a primary requirement. Then an embedded system profile could take exception in cases where that might be needed (I suspect secure embedded systems would also find value in a reasonably large range of UID's -- at least enough to keep a 16 bit value for storing these.) Action: Either add appropriate text to standard to resolve objection (I'd prefer wording on this from the Open Group experts so that it will not require changes to existing implementations of tradtional BSD/SVID systems) Or Provide rationale for rejecting the recomendation that does not dismiss it as out of scope (which would discourage other ballotors from concuring with the objection.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 357 gwc@unisoft.com BUG in XBDd5 sys/types.h (rdvk# 109) {gwc mode_t} Thu, 1 Feb 2001 19:37:37 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 381 Line: 13255 Section: sys/types.h Problem: Since it must be possible to use bitwise AND and OR operations on mode_t values, this means that mode_t effectively has to be an integer type. (Using bitwise operations on other types violates a constraint in the C standard). The specification should state this requirement explicitly instead of leaving it to be deduced. Action: Add the following line after line 13255 : * mode_t shall be an integer type _____________________________________________________________________________ OBJECTION Enhancement Request Number 358 gwc@unisoft.com BUG in XBDd5 sys/types.h (rdvk# 110) {gwc [ug]id_t/nlink_t} Thu, 1 Feb 2001 19:37:37 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 381 Line: 13255 Section: sys/types.h Problem: Currently uid_t and gid_t are only required to be arithmetic types. However, there are various commands such as "id" and "ls -nl" that are required to output UID and GID values using "%u" format (i.e. as unsigned decimal integers). Now that POSIX.1 and POSIX.2 are being merged into a single standard, it would make sense to remove this anomaly by requiring uid_t and gid_t to be integer types. The same applies to nlink_t ("ls -l" uses %u). Also, if uid_t and gid_t are changed to integer types then id_t should be as well (since pid_t is already). I realise it is debatable whether this change is in scope. I believe it is, since it addresses a discrepancy between two base documents. In any case, if the change is considered to be out of scope, it can easily be brought into scope by filing a POSIX interp request. If it is rejected for being out of scope, please give an indication of whether it would be accepted if resubmitted after it has been brought into scope. Action: Add the following line after line 13255 : * nlink_t, uid_t, gid_t and id_t shall be integer types _____________________________________________________________________________ COMMENT Enhancement Request Number 359 gwc@unisoft.com BUG in XBDd5 sys/types.h (rdvk# 112) {gwc time_t/clock_t} Thu, 1 Feb 2001 19:37:37 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 381 Line: 13259 Section: sys/types.h Problem: Following the alignment with C99, time_t can now be a complex type, whereas previously it had to be an integer or a (real) floating type. However, since all time_t values obtained from the system must have real values, if time_t is complex then its imaginary part will always be zero. Thus applications can handle these complex time_t values just the same as if time_t were required to be an "integer or real floating" type. The same applies to clock_t. It would be better for the specification to state explicit requirements for these types than for application writers to have to work out what assumptions about them they can safely make. Action: Add the following line after line 13259 : * time_t and clock_t shall be integer or real floating types _____________________________________________________________________________ COMMENT Enhancement Request Number 360 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 392) [DWC-jf-6] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 395 Line: 13670 Section: termios.h Problem: (FIPS Mandated) With the removal of the FIPS margin header definition as defined in SUSv2's XBD volume, the global FIPS 151-2 requirement on implementations to support the functionality associated with the symbols CS7, CS8, CSTOPB, PARODD, and PARENB needs to be reaffirmed. Action: Add the following new paragraph after P395, L13670: The implementation shall support the functionality associated with the symbols CS7, CS8, CSTOPB, PARODD, and PARENB. Add the following text to the Issue 6 change history after P397, L13731: FIPS 151-2 requirements for symbols CS7, CS8, CSTOPB, PARODD and PARENB are reaffirmed. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 361 drepper@redhat.com Bug in XBDd5 (rdvk# 95) {ud-26} Sun, 28 Jan 2001 04:17:02 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 396 Line: 13709 Section: Problem: The prototype for tcsetattr() is wrong (see XSH). Action: Replace line 13707 with int tcsetattr(int, int, const struct termios *); [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 362 pete.forman@westerngeco.com BUG in XBDd5 (rdvk# 6) [PWF20001220/5] Wed, 20 Dec 2000 14:10:45 +0000 (GMT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 406 Line: 14024 Section: Problem: Typo. Action: Change "" to "" [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 363 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 340) {jjh16} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove "-200x", here and on lines 14255, 14260 and 15040. but also change line 14254 and see ERN 364 _POSIX2_VERSION Integer value indicating version of the Shell and Utilities volume of IEEE Std 1003.1 to which the implementation conforms. For implementations conforming to IEEE Std 1003.1-200x the value shall be 200xxxL. _____________________________________________________________________________ Page: 412 Line: 14252 Section: unistd.h Problem: "Version of IEEE Std 1003.1-200x" makes no sense if "IEEE Std 1003.1-200x" means this version. Action: Remove "-200x", here and on lines 14255, 14260 and 15040. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 364 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 341) {jjh17} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Integer value indicating version of IEEE Std 1003.1 (C-language binding) to which the implementation conforms. For implementations conforming to IEEE Std 1003.1-200x the value shall be 200xxxL. _____________________________________________________________________________ Page: 412 Line: 14252-3 Section: unistd.h Problem: The paragraph seems to repeat itself. Saying "this value shall be used for systems that conform" is unnecessary. Action: Change lines 14252-3 to say: Integer value indicating version of IEEE Std 1003.1 (C-language binding) to which the implementation conforms. The value shall be 200xxxL. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 365 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 342) {jjh18} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make them consistent as xxxL _____________________________________________________________________________ Page: 412 Line: 14253 Section: unistd.h Problem: The values 200xxxL (here) and 200myyL (at line 14308) seem to be used to mean the same thing. Action: Remember to substitute both strings when publishing the standard. _____________________________________________________________________________ COMMENT Enhancement Request Number 366 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 343) {jjh19} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: These were carried forward from a Base document _____________________________________________________________________________ Page: 412-413 Line: 14272-14287 Section: unistd.h Problem: Specifying support for old versions of XPG is inconsistent with the treatment of old versions of POSIX. And is it even possible to simultaneously support several versions (with, for example, the incompatible definitions of cuserid())? Action: Move this information to a non-normative part. See jjh34 for suggested Application Usage. _____________________________________________________________________________ COMMENT Enhancement Request Number 367 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 344) {jjh20} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This methodology was introduced in 1003.1a after much debate. We believe the rationale on page 430 explains this sufficiently. _____________________________________________________________________________ Page: 413 Line: 14289-301 Section: unistd.h Problem: It is not clear how a portable application can allow for the case where a constant is undefined. The existence of headers, etc, is guaranteed if it has the value zero, but not if it is undefined. Why is there a need for 4 cases (-1, 0, +ve, undefined)? It would not be difficult for an implementation to define all the macros. Action: Change lines 14289-91 to say: The following symbolic constants shall be defined in , and shall have a value of -1, 0, or greater, unless otherwise specified below. OR Change to use the three cases (-1, undefined, +ve). This is more compatible with existing applications that take a definition not equal to -1 to mean "always supported". OR Provide an example in Application Usage to show how to test one of these constants and how to conditionally include a header. _____________________________________________________________________________ COMMENT Enhancement Request Number 368 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 345) {jjh21} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 413 Line: 14300 Section: unistd.h Problem: Line 14300 says the application "must" call sysconf() at runtime. This is not necessary if it does not use the associated functions; and even if it does, lines 14302-4 indicate it might not call sysconf(). Action: Change "must" to "can". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 369 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 346) {jjh22} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change sysconf() to "fpathconf(),pathconf() or sysconf()", here and on line 14290 and 14304. _____________________________________________________________________________ Page: 413 Line: 14301 Section: unistd.h Problem: To test some options it is necessary to call pathconf() instead of sysconf(). Action: Add "or pathconf()", here and on line 14304. _____________________________________________________________________________ COMMENT Enhancement Request Number 370 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 348) {jjh24} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 413-8 Line: 14306-521 Section: unistd.h Problem: Almost all the constants are prevented from having the value 0. This may be unintentional. Action: If appropriate, change "other than -1" to "other than -1 or 0". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 371 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 349) {jjh25} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove the phrases _____________________________________________________________________________ Page: 413-8 Line: 14306-521 Section: unistd.h Problem: The text is cluttered with the phrase "the date of approval of IEEE Std 1003.1-200x". Action: Remove the phrases, and have one fuller note at the start of to explain the significance of the value. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 372 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 347) {jjh23} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 413-8 Line: 14306-521 Section: unistd.h Problem: If the ADV shading means "Do not use this name unless you know that the ADV option is supported" then you cannot use it to find out if the option is supported. Likewise for other options. Action: Remove the shading, and add "(ADV margin code)" after "Advisory Information option". Likewise for other options. [Ed recommendation: Reject If the option is not supported then the symbol need not be present. You can test for support using #ifdef] _____________________________________________________________________________ COMMENT Enhancement Request Number 373 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 350) {jjh26} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_374 Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 413-7 Line: 14317-469 Section: unistd.h Problem: Issue 5 of XSH says that _POSIX_CHOWN_RESTRICTED, _POSIX_NO_TRUNC and _POSIX_VDISABLE have values other than -1. Action: Add XSI-shaded notes saying each has a value other than -1. [Ed recommendation: dup ] _____________________________________________________________________________ COMMENT Enhancement Request Number 374 dwc@spartan.eng.sun.com BUG in XBDd5 (rdvk# 393) [DWC-jf-7] Wed, 14 Feb 2001 23:56:22 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 413,414,417 Line: 14320,14357,14469 Section: unistd.h Problem: (FIPS mandated) Mandated FIPS 151-2 requirement on _POSIX_CHOWN_RESTRICTED, _POSIX_NO_TRUNC and _POSIX_VDISABLE not clear. Action: Add the following sentence after P413, L14320: This symbol shall always set to a value other than -1. Add the following sentence after P414, L14357: This symbol shall always set to a value other than -1. Add the following sentence after P417, L14469: This symbol shall always set to a value other than -1. [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 375 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 351) {jjh27} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 415 Line: 14378-380 Section: unistd.h Problem: Since the _POSIX_SAVED_IDS option is always supported, and the functionality is described elsewhere, the details are not needed here. Action: Remove the two sentences starting "The behavior of". [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 376 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 352) {jjh28} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 416 Line: 14445-62 Section: unistd.h Problem: Lack of alphabetic order. Action: Move entry for _POSIX_TIMERS after _POSIX_TIMEOUTS. Move entry for _POSIX_TRACE_LOG after _POSIX_TRACE_INHERIT. [Ed recommendation: Accept] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 377 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 353) {jjh29} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change 14468- to This symbolic constant shall be defined to be the value of a character that shall disable terminal special character handling as described in _____________________________________________________________________________ Page: 417 Line: 14469 Section: unistd.h Problem: It is impossible to use zero as the special _POSIX_VDISABLE value without the application having to call pathconf(). This may be unintentional. Action: Explain whether or not zero is special for _POSIX_VDISABLE. _____________________________________________________________________________ COMMENT Enhancement Request Number 378 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 354) {jjh30} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On page 412 move 14274-6 to follow 14561 on p419; Add unshaded line before 14256 "The following symbolic constant shall be defined only if the implementation supports the XSI option see 2.4.1" Delete 14259-14287. Add to change history The XSI versioning information is reworked as per The Open Group Base Working Group resolution bwg2001-006 _____________________________________________________________________________ Page: 418 Line: 14546 Section: unistd.h Problem: There is no option constant for the X/Open System Interfaces Extension. Action: Add a new constant, or explain (perhaps with an example) what needs to be true before names marked XSI can be used. [Ed recommendation: None Fwd to Base WG, I believe that _XOPEN_UNIX will be the symbol] _____________________________________________________________________________ OBJECTION Enhancement Request Number 379 donnte@microsoft.com Bug in xbdd5 Assorted (rdvk# 303) [DST-279] Mon, 5 Feb 2001 19:56:53 -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: withdrawn by originator _____________________________________________________________________________ Page: 419 Line: 14566 Section: unistd.h Problem: Shallification Action: function can be used to determine whether -> function shall determine whether [Ed recommendation: NONE I think must would be the ideal word here...:-), however I am not sure about shall.] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 380 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 355) {jjh31} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Move lines 14771-903 to after line 14928. _____________________________________________________________________________ Page: 424-7 Line: 14771-928 Section: unistd.h Problem: Lack of alphabetic order (sysconf - lockf - pathconf). Action: Move lines 14771-903 to after line 14928. Alternatively, create a new subsection for sysconf() and pathconf() constants. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 381 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 356) {jjh32} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 424-5 Line: 14775-869 Section: unistd.h Problem: Some _SC_* names are missing (compare sysconf() in XSH). Action: Add _SC_2_CHAR_TIME, _SC_ADVISORY_INFO, _SC_CPUTIME, _SC_SPAWN, _SC_SPORADIC_SERVER, _SC_THREAD_CPUTIME, _SC_THREAD_SPORADIC_SERVER, and _SC_TIMEOUTS. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 382 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 357) {jjh33} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 426 Line: 14775-6 Section: unistd.h Problem: Lack of alphabetic order. Action: Move _SC_TRACE_LOG after _SC_TRACE_INHERIT. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 383 prindle@ieee.org (rdvk# 322) [prindle.xbd-41] Tue, 13 Feb 2001 07:03:28 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 426-438 Line: 15270-15359 Section: Problem: Shading and margin coding is incorrect. Functions and/or semantics marked as XSI extensions are, in fact, in the base C99 standard. Action: Remove shading and XSI margin codes from: lines 15270-15271 line 15277 lines 15291-15302 lines 15315-15316 line 15359 [Ed recommendation: Accept as marked Add to the rationale, In the C standard the symbols referenced as XSI extensions are in wctype.h. Their presence here is thus an extension ] [Note from Clive Feather All these lines should remain shaded and margin coded. While the functions etc. are in the base C99 standard, they are *NOT* in this header; they are in (except FILE, which is in ). Therefore they should remain shaded (if not XSI, then CX).] _____________________________________________________________________________ COMMENT Enhancement Request Number 384 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 358) {jjh34} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add as APPLICATION USAGE (replacing "None"): ======================================================== IEEE Std 1003.1-200x only describes the behavior of systems that claim conformance to it. However, application developers who want to write applications that adapt to other versions of IEEE Std 1003.1 (or to systems that do not conform to any POSIX standard) may find it useful to code them so as to conditionally compile different code depending on the value of _POSIX_VERSION, for example: #if _POSIX_VERSION == 200xxxL /* Use the newer function that copes with large files */ off_t pos=ftello(fp); #else /* Either this is an old version of POSIX, or _POSIX_VERSION is not even defined, so use the traditional function */ long pos=ftell(fp); #endif Earlier versions of IEEE Std 1003.1 and of the Single UNIX Specification are identified by the following macros: POSIX.1: 1988 _POSIX_VERSION==198808L POSIX.1: 1990 _POSIX_VERSION==199009L ISO POSIX-1: 1996 _POSIX_VERSION==199506L Single UNIX Specification Version 1 _XOPEN_UNIX and _XOPEN_VERSION==4 Single UNIX Specification Version 2 _XOPEN_UNIX and _XOPEN_VERSION==500 IEEE Std 1003.1-200x does not make any attempt to define application binary interaction with the underlying operating system. However, application developers might find it useful to query _SC_VERSION at runtime via sysconf() to determine whether the current version of the operating system supports the necessary functionality as in the following program fragment: if (sysconf(_SC_VERSION) < 200xxxL) { fprintf(stderr, "POSIX.1-200x system required, terminating\n"); exit(1); } ============================================================ Delete lines 15040-15063 ============================================================ After after 15039, as part of the same paragraph However, they recognized that support for existing application binaries is a concern to manufacturers, application developers, and the users of implementations conforming to IEEE Std 1003.1-200x and thus decided to retain the definitions. ============================================================ _____________________________________________________________________________ Page: 429-30 Line: 15029-64 Section: unistd.h Problem: Version test macros are easy to implement, but it is more difficult for application writers to see how to use them. There is a need for some Application Usage, but there is just some Rationale that is discouraging with examples that are out of date. Also, the examples do not show how in practice may be more useful to test for a value being greater-or-equal than the required value. Action: Add as APPLICATION USAGE (replacing "None"): ======================================================== IEEE Std 1003.1-200x can only dictate the behavior of systems that claim conformance to it. However, application developers who want to write applications that adapt to other versions of IEEE Std 1003.1 (or to systems that do not conform to any POSIX standard) might find it useful to code them as in the following program fragment: #if _POSIX_VERSION >= 200ymmL /* Use the new function that copes with large files */ off_t pos=ftello(fp); #else /* Either this is an old version of POSIX, or _POSIX_VERSION is not even defined, so use the traditional function */ long pos=ftell(fp); #endif Earlier versions of IEEE Std 1003.1 and of the X/Open Portability Guide are identified by the following macros: POSIX.1: 1988 _POSIX_VERSION==198808L POSIX.1: 1990 _POSIX_VERSION==199009L ISO POSIX-1: 1996 _POSIX_VERSION==199506L Issue 2 _XOPEN_XPG2 (Not specified until Issue 4) Issue 3 _XOPEN_VERSION==3 _XOPEN_XPG3 (Not specified until Issue 4) Issue 4 _XOPEN_VERSION==4 _XOPEN_XPG4 Issue 4, Version 2 _XOPEN_UNIX [THIS NEEDS CHECKING!!] Issue 5 _XOPEN_VERSION==500 _XOPEN_UNIX [THIS NEEDS CHECKING!!] IEEE Std 1003.1-200x does not make any attempt to define application binary interaction with the underlying operating system. However, application developers might find it useful to query _SC_VERSION at runtime via sysconf() to determine whether the current version of the operating system supports the necessary functionality as in the following program fragment: if (sysconf(_SC_VERSION) < 200xxxL) { fprintf(stderr, "POSIX.1-200x system required, terminating\n"); exit(1); } ============================================================ Replace lines 15040-64 by: ============================================================ But they recognized that support for existing application binaries is a concern to manufacturers, application developers, and the users of implementations conforming to IEEE Std 1003.1-200x. While the example using _SC_VERSION in the Application Usage section does not provide the greatest degree of imaginable utility to the application developer or user, it is arguably better than a core dump or some other equally obscure result. (It is also possible for implementations to encode and recognize application binaries compiled in various POSIX.1-conforming environments, and modify the semantics of the underlying system to conform to the expectations of the application.) For the reasons outlined in the preceding paragraphs and in the Application Usage section, the standard developers elected to retain the _POSIX_VERSION and _SC_VERSION functionality. ============================================================ _____________________________________________________________________________ EDITORIAL Enhancement Request Number 385 wollman@lcs.mit.edu Bug in XBDd5 (rdvk# 15) {GAW-6} Tue, 9 Jan 2001 17:37:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 429 Line: 15060-15061 Section: Problem: The example for _SC_VERSION checks against the instant standard (200xxxL) but names it 1990. Action: Change the text printed to match the current standard. [Ed recommendation: Accept as marked line 15061 1990->200x] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 386 Jon Hitchcock Bug in XBDd5 unistd.h (rdvk# 359) {jjh35} Wed, 14 Feb 2001 11:15:16 -0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 432 Line: 15176 Section: unistd.h Problem: Letter "d" missing from function name. Action: Change "realink()" to "readlink()". [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 387 drepper@redhat.com Bug in XBDd5 (rdvk# 8) {ud-9} Thu, 21 Dec 2000 21:56:41 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 436 Line: 15259 Section: Problem: The title of this man pages (wide-character types) comes from the pre-C99 times. It corresponds to the title of but the wide-character equivalent of is now (there used to be no so the title is understandable). Action: Replace the title with something like wchar.h -- wide-character handling Better wording is welcome. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 388 drepper@redhat.com Bug in XBDd5 (rdvk# 86) {ud-18} Fri, 26 Jan 2001 02:39:42 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 442 Line: 15279 Section: Problem: Normally XPG requires all types used in definitions in a header also being defined. This isn't the case with where the va_list type is required in some prototypes but is not allowed to be defined by including . Action: Require defining va_list. Add at line 15279 va_list As described in . This extra text must then be marked XSI. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 389 drepper@redhat.com Bug in XBDd5 (rdvk# 87) {ud-17} Fri, 26 Jan 2001 01:34:17 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 442 Line: 15498 Section: Problem: Normally XPG requires all types used in definitions in a header also being defined. This isn't the case with where the size_t type is required in the wordexp_t definition but is not allowed to be defined by including . Action: Require defining size_t. Add at line 15498 The header shall define the following type: size_t As described in . This extra text must then be marked XSI. [Ed recommendation: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 390 Clive D.W. Feather Bug in XBDd5 (rdvk# 108) [CDWF-517] Wed, 31 Jan 2001 11:18:13 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 565 Line: 3788-3789 Section: abort() Problem: The last sentence (about overriding blocking or ignoring) can be derived from the C Standard. Therefore it should not be CX shaded. Action: Remove the shading from the last sentence. [Ed recommendation: None This is a BUG in XSH] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 391 Clive D.W. Feather Bug in XBDd5 (rdvk# 103) [CDWF-519] Wed, 31 Jan 2001 22:46:42 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Action AJ/Cathy to try and fix _____________________________________________________________________________ Page: 786 Line: 10253,10257,10262 Section: exit() Problem: The CX or XSI shading starts in the wroong place in various bits of text. Action: Extend the shading to include: line 10253: "with the following" line 10257: "and has" line 10262: "and" [Ed recommendation: None This is a BUG in XSH We need to rephrase this since its not possible to have two shaded sections starting on one line. We will need to rework this section] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 392 Clive D.W. Feather Bug in XBDd5 (rdvk# 104) [CDWF-520] Wed, 31 Jan 2001 22:46:42 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 786 Line: 10256 Section: exit() Problem: Missing space after the end of the shading. Action: Insert a space. [Ed recommendation: Accept This is a BUG in XSH] _____________________________________________________________________________ COMMENT Enhancement Request Number 393 Clive D.W. Feather Bug in XBDd5 (rdvk# 105) [CDWF-521] Wed, 31 Jan 2001 22:46:42 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Editors will try an either ... or construct _____________________________________________________________________________ Page: 787 Line: 10268-10273 Section: exit() Problem: It is unclear how the two SIGCHLD bullet points interact. I presume that the second should override the first, but it isn't clear. Action: If there is a way to say "not-XSI" in margin codes, then: - shade lines 10268-10269 with "not-XSI"; - append to line 10273 (still XSI shaded): "Otherwise a SIGCHLD shall be sent to the parent process." Alternatively: - delete lines 10268-10269 - append to line 10273, unshaded: "Otherwise, if the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process." [Ed recommendation: None This is a BUG in XSH]