Document Number: AUSTIN/34 Title: XSH Aardvark Change Request Report Revision Date: 1999-07-28 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XSH Draft 1. Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Accept as marked ERN 3 Accept ERN 4 Accept as marked ERN 5 Reject ERN 6 Accept as marked ERN 7 Accept ERN 8 Accept as marked ERN 9 Accept as marked ERN 10 Reject ERN 11 Reject ERN 12 Accept as marked ERN 13 Reject ERN 14 Accept as marked ERN 15 Accept as marked ERN 16 Accept as marked ERN 17 Accept ERN 18 Accept ERN 19 Accept as marked ERN 20 Reject ERN 21 Accept as marked ERN 22 Reject ERN 23 Accept ERN 24 Reject ERN 25 Accept ERN 26 Accept as marked ERN 27 Accept ERN 28 Accept as marked ERN 29 Reject ERN 30 Accept as marked ERN 31 Duplicate of 30 ERN 32 Accept as marked ERN 33 Accept ERN 34 Duplicate of 32 ERN 35 Accept as marked ERN 36 Reject ERN 37 Accept as marked ERN 38 Accept as marked ERN 39 Accept ERN 40 OPEN ERN 41 Accept as marked ERN 42 Accept as marked ERN 43 Accept ERN 44 Accept ERN 45 Accept ERN 46 Accept as marked ERN 47 Accept as marked ERN 48 Accept as marked ERN 49 Accept as marked ERN 50 Accept as marked ERN 51 Reject ERN 52 Accept ERN 53 Accept ERN 54 Accept as marked ERN 55 Accept as marked ERN 56 Accept as marked ERN 57 Accept as marked ERN 58 Accept ERN 59 Accept as marked ERN 60 Accept as marked ERN 61 Reject ERN 62 Accept as marked ERN 63 Reject ERN 64 Accept as marked ERN 65 Accept as marked ERN 66 Accept ERN 67 Reject ERN 68 Accept as marked ERN 69 Accept ERN 70 Accept ERN 71 Accept as marked ERN 72 Reject ERN 73 Reject ERN 74 Reject ERN 75 Reject ERN 76 Accept ERN 77 Reject ERN 78 Accept ERN 79 Accept as marked ERN 80 Accept as marked ERN 81 Accept ERN 82 Accept as marked ERN 83 Reject ERN 84 Duplicate of 85 ERN 85 Accept ERN 86 Reject ERN 87 Accept as marked ERN 88 Accept ERN 89 Accept as marked ERN 90 Accept as marked ERN 91 Reject ERN 92 Accept as marked ERN 93 Reject ERN 94 Accept as marked ERN 95 Accept as marked ERN 96 Accept ERN 97 Accept ERN 98 Duplicate of 99 ERN 99 Accept ERN 100 Accept as marked ERN 101 Reject ERN 102 Accept as marked ERN 103 Accept ERN 104 Accept as marked ERN 105 Accept ERN 106 Accept ERN 107 Accept ERN 108 Accept ERN 109 Reject ERN 110 Reject ERN 111 Accept as marked ERN 112 Reject ERN 113 Accept ERN 114 Accept ERN 115 Accept ERN 116 Accept ERN 117 Accept as marked ERN 118 Accept as marked ERN 119 Accept as marked ERN 120 Accept as marked ERN 121 Reject ERN 122 Accept as marked ERN 123 Accept as marked ERN 124 Accept as marked ERN 125 Accept ERN 126 Accept as marked ERN 127 Reject ERN 128 Reject ERN 129 Accept ERN 130 Reject ERN 131 Accept as marked ERN 132 Reject ERN 133 Accept ERN 134 Accept as marked ERN 135 Accept ERN 136 Accept as marked ERN 137 Accept ERN 138 Accept as marked ERN 139 Accept ERN 140 Accept as marked ERN 141 Accept as marked ERN 142 Accept as marked ERN 143 Reject ERN 144 Accept ERN 145 Reject ERN 146 Accept ERN 147 Accept as marked ERN 148 Accept as marked ERN 149 Accept ERN 150 Accept as marked ERN 151 Accept as marked ERN 152 Accept ERN 153 Accept ERN 154 Accept ERN 155 Accept ERN 156 Accept ERN 157 Accept as marked ERN 158 Reject ERN 159 Reject ERN 160 Accept as marked ERN 161 Reject ERN 162 Accept as marked ERN 163 Accept ERN 164 Accept as marked ERN 165 Accept as marked ERN 166 Reject ERN 167 Reject ERN 168 Accept as marked ERN 169 Accept as marked ERN 170 Accept ERN 171 Accept ERN 172 Accept ERN 173 Accept as marked ERN 174 Reject ERN 175 Accept ERN 176 Accept ERN 177 Reject ERN 178 Reject ERN 179 Reject ERN 180 Accept ERN 181 Reject ERN 182 Accept ERN 183 Accept ERN 184 Accept ERN 185 Accept ERN 186 Accept ERN 187 Accept as marked ERN 188 Accept ERN 189 Accept as marked ERN 190 Accept as marked ERN 191 Accept as marked ERN 192 Accept as marked ERN 193 Accept as marked ERN 194 Accept ERN 195 Duplicate of 196 ERN 196 Accept ERN 197 Accept ERN 198 Accept ERN 199 Accept ERN 200 Reject ERN 201 Accept as marked ERN 202 Accept ERN 203 Accept as marked ERN 204 Accept as marked ERN 205 Reject ERN 206 Reject ERN 207 Accept ERN 208 Accept as marked ERN 209 Accept ERN 210 Accept ERN 211 Accept ERN 212 Accept as marked ERN 213 Reject ERN 214 Accept as marked ERN 215 Accept as marked ERN 216 Accept as marked ERN 217 Accept as marked ERN 218 Accept ERN 219 Accept as marked ERN 220 Accept as marked ERN 221 Accept ERN 222 Accept ERN 223 Accept ERN 224 Accept ERN 225 Accept as marked ERN 226 Accept ERN 227 Accept ERN 228 Accept ERN 229 Accept as marked ERN 230 Accept ERN 231 Accept as marked ERN 232 Accept ERN 233 Reject ERN 234 Accept ERN 235 Accept ERN 236 Accept ERN 237 Accept as marked ERN 238 Accept ERN 239 Reject ERN 240 Reject ERN 241 Accept as marked ERN 242 Accept as marked ERN 243 Accept as marked ERN 244 Accept ERN 245 Accept ERN 246 Accept ERN 247 Accept ERN 248 Duplicate of 247 ERN 249 Reject ERN 250 Accept as marked ERN 251 Accept ERN 252 Accept ERN 253 Reject ERN 254 Accept ERN 255 Accept as marked ERN 256 Duplicate of 257 ERN 257 Accept as marked ERN 258 Accept ERN 259 Accept as marked ERN 260 Accept as marked ERN 261 Reject ERN 262 Accept ERN 263 Accept as marked ERN 264 Accept as marked ERN 265 Accept ERN 266 Accept as marked ERN 267 Reject ERN 268 Reject ERN 269 Reject ERN 270 Accept ERN 271 Accept ERN 272 Accept as marked ERN 273 Accept ERN 274 Accept as marked ERN 275 Duplicate of 274 ERN 276 Accept ERN 277 Accept ERN 278 Reject ERN 279 Accept ERN 280 Accept ERN 281 Accept ERN 282 Accept as marked ERN 283 OPEN ERN 284 Accept as marked ERN 285 Accept as marked ERN 286 OPEN ERN 287 OPEN ERN 288 Accept ERN 289 Accept as marked ERN 290 Accept ERN 291 Accept as marked ERN 292 OPEN ERN 293 Accept ERN 294 Accept as marked ERN 295 Reject ERN 296 Reject ERN 297 Accept as marked ERN 298 OPEN ERN 299 OPEN ERN 300 Accept ERN 301 Accept ERN 302 Accept as marked ERN 303 Accept as marked ERN 304 OPEN ERN 305 Accept ERN 306 OPEN ERN 307 Accept ERN 308 Reject ERN 309 OPEN ERN 310 Accept ERN 311 Accept ERN 312 Accept ERN 313 Reject ERN 314 Accept ERN 315 Accept as marked ERN 316 Reject ERN 317 Accept as marked ERN 318 Accept ERN 319 OPEN ERN 320 Accept ERN 321 Reject ERN 322 Accept ERN 323 Accept ERN 324 Accept ERN 325 OPEN ERN 326 Accept ERN 327 Accept ERN 328 OPEN ERN 329 OPEN ERN 330 OPEN ERN 331 OPEN ERN 332 OPEN ERN 333 Accept as marked ERN 334 OPEN ERN 335 OPEN ERN 336 OPEN ERN 337 OPEN ERN 338 OPEN ERN 339 OPEN ERN 340 Accept ERN 341 OPEN ERN 342 Reject ERN 343 Accept as marked ERN 344 Accept ERN 345 OPEN ERN 346 Accept as marked ERN 347 OPEN ERN 348 Accept as marked ERN 349 Accept ERN 350 Accept ERN 351 Accept as marked ERN 352 Accept ERN 353 OPEN ERN 354 Accept ERN 355 Accept* ERN 356 Accept ERN 357 Accept as marked ERN 358 Reject ERN 359 Accept ERN 360 Accept ERN 361 OPEN ERN 362 Accept ERN 363 OPEN ERN 364 OPEN ERN 365 Accept ERN 366 Duplicate of 365 ERN 367 Accept ERN 368 OPEN ERN 369 Accept as marked ERN 370 Accept ERN 371 Accept ERN 372 OPEN ERN 373 Accept as marked ERN 374 OPEN ERN 375 Accept ERN 376 OPEN ERN 377 Duplicate of 378 ERN 378 Accept ERN 379 Accept ERN 380 Accept as marked ERN 381 Accept ERN 382 Accept ERN 383 Accept ERN 384 Accept as marked ERN 385 Accept ERN 386 OPEN ERN 387 OPEN ERN 388 OPEN ERN 389 Accept ERN 390 Accept as marked ERN 391 OPEN ERN 392 Reject ERN 393 OPEN ERN 394 OPEN ERN 395 OPEN ERN 396 Accept as marked ERN 397 OPEN ERN 398 Accept ERN 399 Accept ERN 400 Accept as marked ERN 401 Reject ERN 402 OPEN ERN 403 OPEN ERN 404 OPEN ERN 405 OPEN ERN 406 Accept ERN 407 Reject ERN 408 Accept ERN 409 OPEN ERN 410 Accept ERN 411 Accept ERN 412 Accept ERN 413 Accept ERN 414 Accept ERN 415 Reject ERN 416 POPEN ERN 417 OPEN ERN 418 OPEN ERN 419 Accept as marked ERN 420 OPEN ERN 421 Accept ERN 422 Accept as marked ERN 423 Accept ERN 424 Accept ERN 425 Accept ERN 426 Accept as marked ERN 427 OPEN ERN 428 Accept as marked ERN 429 Accept as marked ERN 430 Accept as marked ERN 431 OPEN ERN 432 Accept ERN 433 Accept as marked ERN 434 OPEN ERN 435 OPEN ERN 436 OPEN ERN 437 Accept ERN 438 Accept ERN 439 Accept ERN 440 Accept ERN 441 Accept ERN 442 Accept as marked ERN 443 Accept as marked ERN 444 Accept as marked ERN 445 Reject ERN 446 Accept as marked ERN 447 Accept as marked ERN 448 Accept as marked _____________________________________________________________________________ Comment Enhancement Request Number 1 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 438) [LD-XSH-1] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This was handled as a separate item on the agenda, see the project scheduling. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Circumstances and timing were such that I was unable to dedicate any signicant chunk of time to reviewing this draft as is evident from the comments that follow. However, given the scope of the changes to the merged specifications, even had I had the time, the review period for this initial draft was too short. Action: Increase the review period for the next draft. _____________________________________________________________________________ comment Enhancement Request Number 2 Frank Bug in XSH (rdvk# 4) [prindle.xsh-0] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This issue as to which version of C to align with has been added to the issues list. _____________________________________________________________________________ Page: all Line: all Section: all Problem: Alignment with ISO C (for functions which also appear in ISO C) is going to be a sticky issue, with ISO for sure, because we hopefully will be getting permission to duplicate these functions here. I don't have an ISO C document handy, so can't check this (and don't really have the energy at this point), but I strongly doubt that every bit of wording that isn't shaded and marked CX is 100% identical to the C standard. I particular, I am having a hard time with the issue of what the C standard specifies as possible values of errno for each function (seems hit-or-miss). To the best of my knowledge, ISO C only specifies EDOM, ERANGE, and EILSEQ errno values, and even then, some functions may set one or more of these into errno on error, and some are required to do so. So anywhere in the document that any other error NAME appears without CX shading is highly suspect, either in the ERRORS section or elsewhere. Several ANSI C references (I do have access to) provide spotty references to undefined errno values falling out of certain functions (ftell() for example: On failure, the ftell function returns -1L and stores an implementation- defined positive value in errno.) Another anomaly is that fseek(), ftell(), and ungetc() in ISO C surely have special caveats in their semantics about binary vs. text files which do not survive here (because text files in conforming systems are treated the same as binary files), yet the absence of those caveats is not marked in any way. Code which assumes these functions work the same on text files is portable to other UNIX branded systems, but certainly isn't portable to all C implementations, and may not be portable to all POSIX implementations (in other words, perhaps the restrictions/caveats ought to come back as normative). In general, even minor wording differences (not marked CX) are going to cause problems with ISO. A spot check of fsetpos() (with my references, which may not exactly track the standard) shows a couple of minor wording differences, including a "shall" that got changed to a "must" and a different description of what was stored in errno. Another example: in qsort(), we use different names for the arguments from ISO C (at least based on my references). Another example: in longjmp(), discussions about calls being in the same thread are clearly not from ISO C. Action: Before the next draft, it would be advisable to go through every ISO C function and header and "strictly" align it with ISO C (all unshaded text exactly as in ISO C, and all text not exactly as in ISO C shaded - deleted text shaded with strike through). I think that is the only way ISO will even think of allowing us to describe these functions in their entirety here. For the time being, see my other objections and comments where I think I may have identified specific instances of departure from correct alignment (but surely haven't caught them all, and may have done some incorrectly). ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 3 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 439) [LD-XSH-2] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: x Line: 247-249 Section: This Problem: The "Issue" reference for XBD, XCU, and XSH is incorrect. Action: Change Issue 5 to Issue 6. _____________________________________________________________________________ Editorial Enhancement Request Number 4 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 440) [LD-XSH-3] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note will be added to the next draft asking for specific wording changes. _____________________________________________________________________________ Page: 1-2 Line: 22-44 Section: 1.1 Problem: The scope is too realtime and threads specific. While this was appropriate for the POSIX.1-1996 specification which was the source of this text, the newly merged XSH covers much more. Action: Update the scope to include other major areas of coverage in XSH. _____________________________________________________________________________ Comment Enhancement Request Number 5 donn@interix.com BUG in XSH (rdvk# 244) [DT-XSH-1] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: We agree that in general definitions do belong in XBD, but we disagree with this specific case - the wording is the same as per .1-1996 and is setting up scope specific definitions _____________________________________________________________________________ Page: 1 Line: 27, Section: 1.1 Problem: Do the definitions of "realtime" and "threads" belong in XBD? Action: Move them there. Since this is really a single document, just put them in XBD. (Note... I have other comments below in the same direction.) (In general, I'd prefer to see definitions in one place, so I know where to look for them, and given the proposed model for the document as a whole, I think that that makes sense.) _____________________________________________________________________________ Objection Enhancement Request Number 6 donn@interix.com BUG in XSH (rdvk# 245) [DT-XSH-2] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: For the next draft we will enable rationale bars on the change history front matter to make it clear _____________________________________________________________________________ Page: 4-5 Line: 87-226 Section: 1.3 Problem: This is rationale, not normative. Action: Move to/mark as non-normative text. (It may be that after editing, this will happen naturally, but just to be sure.) Hold as an open objection until style is resolved. _____________________________________________________________________________ Editorial Enhancement Request Number 7 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 441) [LD-XSH-4] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 6-7 Line: 171-213 Section: 1.3.3 Problem: Table is split across pages. Action: Keep table on a single page. _____________________________________________________________________________ Editorial Enhancement Request Number 8 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 442) [LD-XSH-5] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "capability is" -> "requirements are" _____________________________________________________________________________ Page: 7 Line: 217-220 Section: 1.3.4 Problem: What is the "POSIX System Interfaces capability"? Why not refer to this as the {_POSIX_BASE} option or POSIX Systems Interface Conformance as used elsewhere in the document? Action: Substitute "capability" for "conformance" or even "requirements", or change to use {_POSIX_BASE} option. _____________________________________________________________________________ Objection Enhancement Request Number 9 donn@interix.com BUG in XSH (rdvk# 246) [DT-XSH-3] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change line 228 to: The following terms used are copied from XBD and included here for reference. _____________________________________________________________________________ Page: 8-9 Line: 227-279 Section: 1.4 Problem: This is a repeat of the text in XBD; even if they're supposed to be identical, one should explicitly defer to or refer to the other. Since XBD is the right place... Action: Refer to XBD for this. (Or just remove from here, relying on XBD for all such text.) _____________________________________________________________________________ Editorial Enhancement Request Number 10 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 443) [LD-XSH-6] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The group felt that the existing text is ok as is and the change would not improve it. _____________________________________________________________________________ Page: 8 Line: 235 Section: 1.4 Problem: I know what the sentence means but it still seems a bit odd on first reading how something that is not defined can be selected. Action: Remove the part of the sentence that reads "but is selected by an implementation". It is not needed in the context of the rest of the definition. _____________________________________________________________________________ Objection Enhancement Request Number 11 donn@interix.com BUG in XSH (rdvk# 247) [DT-XSH-4] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Not true, shading is needed for XSI extensions. Style will be addressed elsewhere under a separate agenda item _____________________________________________________________________________ Page: 12 Line: 299 Section: 1.7 Problem: Now that this paragraph is self-referential, it's truly nonsensical. Action: Delete. Note: I suspect that the only base standard that will need this sort of shaded text treatment is the C standard. In all other cases, the feature is either in or out of this document. I'm tempted to suggest reversal of the code: shaded text is copied from some other standard, and defers to that other standard; non-shaded text is normative in this standard. As an issue of style, I suspect that ISO will have problems with the import of a statement varying with such extremely typographic features as shading, particularly within a single sentence. That's another issue to add to the style list. (We should talk separately about some other mechanism besides shading: it pushes the limits of some printers.) _____________________________________________________________________________ objection Enhancement Request Number 12 Frank Bug in XSH (rdvk# 5) [prindle.xsh-1] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This will be handled as per the XBD, there will be one single set of codes. _____________________________________________________________________________ Page: 12 Line: 306-330 Section: 1.7.1 Problem: The set of codes documented here differ from the sets of codes documented in the corresponding section of XBD. I would expect XBD to be the official document defining all codes, with these repeated verbatim here only for convenience. Action: Move all codes which apply to XSH into XBD. Optionally, for convenience of the reader, include the exact same code descriptions here, indicating that these are identical to those in XBD and reproduced for convenience; it is permissible to omit codes here which do not appear in XSH, though I suspect this would be more trouble than it is worth (in keeping the docs sync'ed). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 13 Frank Bug in XSH (rdvk# 17) [prindle.xsh-13] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: XSI is being used for X/Open System Interface extension _____________________________________________________________________________ Page: 12 Line: 313-314 Section: 1.7.1 Problem: The XSI code (formerly EX) is used extensively to highlight extensions to both POSIX and ISO C. I suggest it only be used to mark extensions to POSIX, while CX be used exclusively to mark extensions to ISO C. This will alleviate a lot of confusion later on. This sentence is incorrect as it stands. Also, what does XSI stand for, anyway. I preferred the EX; changing it to UX makes more sense than XSI, unless XSI stands for something really profound. Action: Delete the sentence "Functionality...ISO C standard." Use a meaningful margin code instead of XSI, and restrict the use of this code to extensions to the approved POSIX functionality, not for extensions to ISO C. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 14 donn@interix.com BUG in XSH (rdvk# 248) [DT-XSH-5] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Should be updated to be "XSI conformant" on line 329, delete the rest as Donn suggests. _____________________________________________________________________________ Page: 12 Line: 330 Section: 1.7 Problem: "certain formal standards". I presume this now becomes self-referential and is meaningless. If it does have a meaning, the citation should be specific, not hand-wavy. Action: Delete _____________________________________________________________________________ Comment Enhancement Request Number 15 donn@interix.com BUG in XSH (rdvk# 249) [DT-XSH-6] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is added to the issues list, so it can be recorded _____________________________________________________________________________ Page: 13 Line: 359 Section: 1.8 Problem: Putting normative text in Application Usage sections, as is reflected by a number of Change History sections, is a particularly easy trap to fall into. Be very careful that normative material does not slip into these sections. (A separate review pass is probably indicated as the document nears completion.) Action: Record action item for near the end: review A.U. sections for normative text. _____________________________________________________________________________ Comment Enhancement Request Number 16 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 444) [LD-XSH-7] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The system shall support all required functions defined within this document that are described by the {_POSIX_BASE} option" (see section 2.1.3 on page 16)" to "The system shall support all functions defined within this document that are required for POSIX System Interfaces Conformance (see section 2.1.3 on page 16)". _____________________________________________________________________________ Page: 15 Line: 381 Section: 2.1.1 Problem: I find the reference to {_POSIX_BASE} option a bit confusing since it's never really defined as best I can tell. In section 2.1.3 (POSIX System Interfaces Conformance, it is stated that {_POSIX_BASE} shall be set to something other than -1 implying that POSIX System Interfaces conformance and the {_POSIX_BASE} option are the same, but for the uninitiated, this may be a bit confusing. Action: Change "The system shall support all required functions defined within this document that are described by the {_POSIX_BASE} option" (see section 2.1.3 on page 16)" to "The system shall support all functions defined within this document that are required for POSIX System Interfaces Conformance (see section 2.1.3 on page 16)". Or more clearly define the {_POSIX_BASE} option. _____________________________________________________________________________ Comment Enhancement Request Number 17 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 445) [LD-XSH-8] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 15 Line: 391 Section: 2.1.1 Problem: Reference is made to a Strictly Conforming POSIX System Interfaces Application before the term is defined. Action: Add a reference to section 2.2.1 for the definition. _____________________________________________________________________________ Editorial Enhancement Request Number 18 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 446) [LD-XSH-9] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 16 Line: 426-427 Section: 2.1.3 Problem: The sentence on lines 426 and 427, when considered in the context of the sentence on lines 445 an 446, implies that the option groups listed on lines 428-441 are not part of the Profiling Option groups when in fact they are. Action: Change "reflecting mandatory Option Groups..." to "reflecting mandatory Profiling Option Groups..." _____________________________________________________________________________ Comment Enhancement Request Number 19 donn@interix.com BUG in XSH (rdvk# 250) [DT-XSH-7] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 442-444 look for NGROUPS_MAX within the text and insure if has a min value of 8 _____________________________________________________________________________ Page: 16 Line: 443-444 Section: 2.1.3 Problem: This is "self-profiling", which is sort of strange. Action: Make these simply mandatory. _____________________________________________________________________________ Objection Enhancement Request Number 20 donn@interix.com BUG in XSH (rdvk# 251) [DT-XSH-8] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the scope of the project is producing both an IEEE POSIX standards and The Open Group technical standard , so this is more than just a POSIX document. _____________________________________________________________________________ Page: 18 Line: 493 Section: 2.1.4 Problem: Presumably, this whole section simply becomes required features, and the section disappears. (Although individual parts might not make it.) Action: Action item: each XSI should be examined, and either made mandatory, a feature based upon some other option, or deleted. (I'm aware of the intent that XSI means "SUS extension to POSIX" to be published in the POSIX document". Whether that will happen remains to be seen.) _____________________________________________________________________________ Comment Enhancement Request Number 21 donn@interix.com BUG in XSH (rdvk# 252) [DT-XSH-9] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take option 1 below _____________________________________________________________________________ Page: 21 Line: 626 Section: 2.1.5.2 Problem: The language here is, well, strange. Action: "shall be defined by the implementation". Or "...shall be defined". Personally, I think that making these implementation defined (and thus in the PCD) would be a good thing, so "...are implementation defined" would be even better. _____________________________________________________________________________ Editorial Enhancement Request Number 22 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 447) [LD-XSH-10] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This wording is from existing POSIX.1 and no better wording has been suggested. _____________________________________________________________________________ Page: 23 Line: 693-696 Section: 2.1.6 Problem: It's not clear what this statement is saying, specifically, the part of the sentence that reads "...reflect implementation options for this document that could warrant requirement by Conforming POSIX System Interfaces Applications, or in specifications of conforming systems, or both. Action: Clarify. I assume that what is being said, that though these are "Options", some of these will be required for POSIX System Interfaces Conformance. I'm not sure what requirement there is on the application. _____________________________________________________________________________ objection Enhancement Request Number 23 Frank Bug in XSH (rdvk# 6) [prindle.xsh-2] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 23-26 Line: 697-843 Section: 2.1.6 Problem: While I don't object to listing these options here, the margin codes used here have not been defined as to their meaning as margin codes. It would be best if one did not have to look in multiple places for codes, but that ALL codes be introduced in XBD section 1.3 (1.3.1?) Codes. Action: List and describe in section 1.3 (perhaps 1.3.1, since a level of section numbering seems to be missing there) all codes for specific XSH options, thereby creating a master reference for margin codes. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 24 donn@interix.com BUG in XSH (rdvk# 253) [DT-XSH-10] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Required for XSI _____________________________________________________________________________ Page: 28 Line: 897 Section: 2.2.4 Problem: Remove section (and 2.2.5). There's no new class of conformance defined here, since this will be POSIX. (For the record...) Action: Remove. _____________________________________________________________________________ Objection Enhancement Request Number 25 donn@interix.com BUG in XSH (rdvk# 254) [DT-XSH-11] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept, leave as is, remove reviewers note on l929 _____________________________________________________________________________ Page: 30 Line: 931 Section: 2.4 Problem: To answer the question: no. We need to retain this wording in POSIX to avoid certain classes of toy (or useless) implementations: those that use a crippled linker that can handle only (e.g.) 6 character monocase identifiers. (If the C standard were to insist that a decent linker be used, then we could drop this.) There is just too much code in non-C languages that assumes a decent linker to consider programs limited old linkers as portable. (Otherwise, for a (e.g.) Fortran program to be POSIX conforming and portable, it would have to be have all (external) identifiers as 6 character monocase, which would be pretty onerous in today's world. (It would also require recasting all the identifiers in this document (when used from Fortran) to 6 character monocase. That would be painful.)) Action: Leave as is. _____________________________________________________________________________ Objection Enhancement Request Number 26 donn@interix.com BUG in XSH (rdvk# 255) [DT-XSH-12] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete line 979-981 _____________________________________________________________________________ Page: 32 Line: 979 Section: 3.1 Problem: This would force the "one header per function" rule on POSIX. I'm of mixed mind about that, and this needs to be discussed. Action: Arrive at a consensus for POSIX (not TOG) and implement that. If the consensus is to require multiple headers, fix the individual pages. _____________________________________________________________________________ Editorial Enhancement Request Number 27 donn@interix.com BUG in XSH (rdvk# 256) [DT-XSH-13] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 33 Line: 989 Section: 3.2 Problem: Spelling. Action: "headerin" -> "header in" _____________________________________________________________________________ Objection Enhancement Request Number 28 donn@interix.com BUG in XSH (rdvk# 257) [DT-XSH-14] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: mark as XSI specific, add text on how to compile a POSIX application _____________________________________________________________________________ Page: 33 Line: 994 Section: 3.2 Problem: Delete refs to X/Open and XOPEN_SOURCE; this is POSIX. Action: Delete. (Or if it becomes possible to mix SUS and POSIX in a single document, mark as SUS specific.) _____________________________________________________________________________ Editorial Enhancement Request Number 29 donn@interix.com BUG in XSH (rdvk# 258) [DT-XSH-15] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See l 1012 _____________________________________________________________________________ Page: 33 Line: 1012 Section: 3.2.1 Problem: English problem (probably exacerbated in possible translations). Action: "reserved for use" -> "reserved for implementations" or "reserved to the implementation" (in several places). Yes, I realize that the first sentence says that, but the numbered sentences could be clearer. _____________________________________________________________________________ comment Enhancement Request Number 30 Frank Bug in XSH (rdvk# 7) [prindle.xsh-3] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add nice() and mrand48() , add reviewers note for this to be checked. _____________________________________________________________________________ Page: 37 Line: 1155-1180 Section: 3.2 Problem: I suspect that line 1183 is a true statement; however, the table, as shown, is incomplete. Assuming it is supposed to list all the XSI marked function names, it certainly has missed some, for example, nice() and mrand48(). Action: Delete the table. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 31 donn@interix.com BUG in XSH (rdvk# 259) [DT-XSH-16] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_30 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 37 Line: 1183 Section: 3.2.1 Problem: To answer the question: yes the table *can* be removed because the normative text covers it. However, like the similar Annex in the -1990 POSIX, such tables are very useful, so retaining them (and keeping them current) as rationale is still useful. Action: Move to rationale, but keep. _____________________________________________________________________________ objection Enhancement Request Number 32 Frank Bug in XSH (rdvk# 9) [prindle.xsh-5] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note will be added in the next draft to make the MAN marking more obvious _____________________________________________________________________________ Page: 37 Line: 1191 Section: 3.2 Problem: This is the first instance of the use of margin code MAN. It appears extensively throughout XBD and XCU as well as XSH. It is not defined in the codes or options sections of any of these documents (it is defined in reviewers notes, but this is not normative, nor part of this document). Action: Define the meaning of margin code MAN in the codes section of 1.3. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 33 donn@interix.com BUG in XSH (rdvk# 260) [DT-XSH-17] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: do -> shall 1217 does > shall 1222 _____________________________________________________________________________ Page: 38 Line: 1216,1222 Section: 3.3 Problem: These uses of "do" and "does" are particularly weak, as they sound more like observations than requirements: use shall. Action: Use shall. _____________________________________________________________________________ Objection Enhancement Request Number 34 donn@interix.com BUG in XSH (rdvk# 261) [DT-XSH-18] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_32 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 38 Line: 1227 Section: 3.3 "MAN" is undefined; if I read it correctly, this means "mandatory extension", which is fine, and I hope that these will be edited into simple normative text. However, if I misunderstand the notation... Action: Get rid if it (probably by making it all normative). _____________________________________________________________________________ objection Enhancement Request Number 35 Frank Bug in XSH (rdvk# 180) [prindle.xsh-176] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Copy the strfmon() wording for these _____________________________________________________________________________ Page: 38 Line: 1229-1232 Section: 3.3 Problem: See also page 1245 line 37908 section . In addition to the description given here, this error is used in at least 2 other situations: 1. Lack of room in an output buffer (e.g.: strfmon()). 2. argument exceeding a system defined limit (e.g.: semop()) Action: Add two other definitions for this error number corresponding to the other uses. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 36 Lee.Damico@eng.sun.com Bug in XSH (rdvk# 448) [LD-XSH-11] Wed, 14 Jul 1999 19:56:42 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 38-44 Line: 1229-1483 Section: 3.3 Problem: The error description format in both the current XSH and POSIX specifications has the summary description on it's own line, followed by the more detailed description on the line below that. Action: Restore format as per current released specifications. _____________________________________________________________________________ objection Enhancement Request Number 37 Frank Bug in XSH (rdvk# 10) [prindle.xsh-6] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: errors will be combined rather than having multiple definitions of the same error _____________________________________________________________________________ Page: 40 Line: 1414 Section: 3.3 Problem: It is not clear why this error should be shaded in this way (given that MAN is an undefined code, but that it clearly must mean something, and in general in this section seems to mean that the error is generated by a function from XNS). Other error numbers to which this objection applies: EINPROGRESS (1st of 2) EINTR EINVAL ETIMEDOUT (2nd of 2) Action: Eliminate shading and margin code for this error, retaining an appropriate margin code and shading for the phrase "or offset maximum...description." if this is from an extension or optional interface (appears to be XSI???). For other 4 errors, remove shading and margin code. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 38 Frank Bug in XSH (rdvk# 8) [prindle.xsh-4] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: this is a troff error, EMULTIHOP belongs here _____________________________________________________________________________ Page: 41 Line: 1345-1346 Section: 3.3 Problem: The shading, shaded text, and margin code do not appear to belong here. Other error numbers to which this editorial comment applies: EMSGSIZE (2nd of 2) Action: Remove the margin code and the shaded text "Reserved" here and on the second EMSGSIZE. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 39 Frank Bug in XSH (rdvk# 11) [prindle.xsh-7] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 41 Line: 1362-1363 Section: 3.3 Problem: If EBADMSG was shaded and marked XSI, then ENODATA should be too. Action: Shade and mark this error number as XSI. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 40 donn@interix.com BUG in XSH (rdvk# 262) [DT-XSH-19] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: action: refer to OGTGbase _____________________________________________________________________________ Page: 45 Line: 1520 Section: 3.4 Problem: How is stderr opened: input only (not likely), output only (of course) or both (there's the rub)? Action: My preference: "stderr is opened for input and output, although it is expected that under normal circumstances it will not be used for input". I'm OK with "stderr is opened for output. Implementations may open it for input as well, but a conforming application should not expect that." _____________________________________________________________________________ Objection Enhancement Request Number 41 donn@interix.com BUG in XSH (rdvk# 264) [DT-XSH-21] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: crib wording from posix, section 8.2.3 p 213 l 346 (~l298) _____________________________________________________________________________ Page: 46 Line: 1525-... Section: 3.4.1 Problem: It appears the definition of "underlying function" disappeared somewhere (or did I just miss it). Action: Crib from current POSIX. The real reason for "underlying function" references is to assure that as those functions may change, the change to stdio is handled automatically. _____________________________________________________________________________ Editorial Enhancement Request Number 42 donn@interix.com BUG in XSH (rdvk# 263) [DT-XSH-20] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note will be added in the next draft , giving the alternate wording below, so that the reviewers can take a choice _____________________________________________________________________________ Page: 46 Line: 1534 Section: 3.4.1 Problem: "This exception does not include" is somewhat ambiguous. Action: "As an exception to the exception, the file descriptor underlying a stream is not considered a handle, whether..." _____________________________________________________________________________ Objection Enhancement Request Number 43 donn@interix.com BUG in XSH (rdvk# 265) [DT-XSH-22] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 47 Line: 1586 Section: 3.4.1 Problem: Another wimpy observation that should be a requirement. Action: "implementations shall ensure that an application...". _____________________________________________________________________________ editorial Enhancement Request Number 44 Frank Bug in XSH (rdvk# 12) [prindle.xsh-8] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1718-1723 Section: 3.6 Problem: The table is chopped off at the bottom. Action: Fix formatting so that whole table shows. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 45 Frank Bug in XSH (rdvk# 13) [prindle.xsh-9] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1724-1725 Section: 3.6 Problem: The referenced functions are not XSI extensions, they are realtime options. Action: Remove "XSI" from this sentence. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 46 Frank Bug in XSH (rdvk# 14) [prindle.xsh-10] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Action on Frank to help with the shading. Delete "For the definition of realtime.." _____________________________________________________________________________ Page: 53-60 Line: 1763-2076 Section: 3.7 Problem: There is a curious mix of ways of denoting optional functionality in this section. Mostly, the section relies on "xxx is dependent on option yyy" text. But the memory management subsection 3.7.3 suffers from this when it says "Memory management is dependent on support of the Mapped Files option." because clearly it is dependent on any of a number of options (at least 4) in various ways; later in this subsection, the Shared Memory option is introduced using shading, as is the Memory Protection option. The Process Memory Locking and Range Memory Locking options are not addressed. Action: Since shading seems necessary in 3.7.3, use shading and margin markers throughout section to denote which option various text is dependent upon, eliminating the intro sentences. Since 3.7.3 does not address MLR or ML options, add these shadings where appropriate. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 47 donn@interix.com BUG in XSH (rdvk# 266) [DT-XSH-23] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: take the bulleted list, move to XBD. simplify the existing bullet list remaining here, "Semaphores, as defined in XBD section 2.x.x.x" _____________________________________________________________________________ Page: 53 Line: 1789-1797 Section: 3.7 Problem: These are definitions. They belong in the definitions section of the main volume. Action: Move to XBD. See prior comments on use of XBD. _____________________________________________________________________________ Objection Enhancement Request Number 48 donn@interix.com BUG in XSH (rdvk# 267) [DT-XSH-24] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "Extended signal" -> "Realtime signal" on l 1799 & 1798 _____________________________________________________________________________ Page: 53 Line: 1799 Section: 3.7 Problem: Not all signal generation, just extended. Action: "Signal generation and delivery" -> "Extended signal generation and delivery" (or something even more descriptive.) _____________________________________________________________________________ Editorial Enhancement Request Number 49 donn@interix.com BUG in XSH (rdvk# 268) [DT-XSH-25] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We'll insert the wording that Donn provides, if any, as a reviewers note for the next draft. _____________________________________________________________________________ Page: 57 Line: 1941 Section: 3.7.3 Problem: This text is very choppy and hard to follow. Action: If others agree, I'll take an Action Item to try and improve it. _____________________________________________________________________________ Objection Enhancement Request Number 50 donn@interix.com BUG in XSH (rdvk# 269) [DT-XSH-26] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept as below, but the line reference is line 57 _____________________________________________________________________________ Page: 59 Line: 1969 Section: 3.7.4 Problem: Anathema: "may not" Action: "may or may not" -> "may but need not" _____________________________________________________________________________ Objection Enhancement Request Number 51 donn@interix.com BUG in XSH (rdvk# 270) [DT-XSH-27] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the wording at the moment is taken verbatim from .1, if thought to be incorrect an interpretation request should be filed. _____________________________________________________________________________ Page: 60 Line: 2071 Section: 3.7.5 Problem: Garbled so as to be at best wrong. As it stands, it sets a ceiling, not a floor, on the precision of the clock. Action: "The maximum allowable resolution" -> "The minimum allowable resolution" or "The maximum allowable interval". _____________________________________________________________________________ objection Enhancement Request Number 52 Frank Bug in XSH (rdvk# 96) [prindle.xsh-92] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 62-63 Line: 2155-2167 Section: 3.8.2 Problem: Function crypt() is missing from this table. Action: Add crypt() to the list of non thread-safe functions. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 53 Frank Bug in XSH (rdvk# 95) [prindle.xsh-91] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 62-63 Line: 2155-2167 Section: 3.8.2 Problem: See also line 2357,39212,40342,40394. Functions gamma() and getw() are not in this standard and should not be referenced here. Action: Delete references to gamma() and getw() wherever they appear. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 54 Frank Bug in XSH (rdvk# 218) [prindle.xsh-214] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add after this line: "The wcrtomb() and wcsrtombs() functions need not be thread safe if passed a NULL ps argument." Also, add the other functions wcstombs() and wctomb() to the first (unshaded) table above. _____________________________________________________________________________ Page: 63 Line: 2169 Section: 3.8.2 Problem: The functions wcrtomb() and wcsrtombs() also may not be thread safe if they are passed a NULL ps argument (depends on the resolution of [prindle.xsh-213]). Action: If these functions are determined not to be thread safe, add after this line: "The wcrtomb() and wcsrtombs() functions need not be thread safe if passed a NULL ps argument." Also, add the other functions wcstombs() and wctomb() to the first (unshaded) table above. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 55 Frank Bug in XSH (rdvk# 97) [prindle.xsh-93] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete line 2170 _____________________________________________________________________________ Page: 63 Line: 2170 Section: 3.8.2 Problem: This is a sweeping generalization that applied to a former draft, but I don't see how it applies to the current draft. The only LEGACY functions which are inherently likely to be implemented as non-reentrant are already in the list above. Also, the other legacy functions (not in the list above) do not have words in their description that permit them to be non-reentrant (this paragraph and individual function descriptions need to be kept consistent). Action: Either delete this line (preferrable solution), or add the "non-reentrant, not thread safe" disclaimer to the DESCRIPTION section of each of the following LEGACY functions: bcmp(), bcopy(), bzero(), ftime(), getwd(), index(), mktemp(), rindex(), utimes(). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 56 donn@interix.com BUG in XSH (rdvk# 271) [DT-XSH-28] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the whole section 3.8.4 is rationale _____________________________________________________________________________ Page: 63 Line: 2183 Section: 3.8.4 Problem: This appears to be rationale, marked as a MAN extension. Action: Extract anything normative, and move the rest to rationale. _____________________________________________________________________________ objection Enhancement Request Number 57 Frank Bug in XSH (rdvk# 242) [prindle.xsh-238] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add "as defined in pthread.h" _____________________________________________________________________________ Page: 66 Line: 2324-2335 Section: 3.8.9.1 Problem: Where are PTHREAD_CANCEL_DISABLE, PTHREAD_CANCEL_ENABLE, PTHREAD_CANCEL_ASYNCHRONOUS, and PTHREAD_CANCEL_DEFERRED defined? This is a P1003.1n issue. Action: Clarify they are defined in . Shade and mark MAN. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 58 Frank Bug in XSH (rdvk# 98) [prindle.xsh-94] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 68 Line: 2380 Section: 3.8.9.2 Problem: See also line 40352,40394. Function putw() is not in this standard and should not be referenced here. Action: Delete references to putw() wherever they appear. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 59 Frank Bug in XSH (rdvk# 243) [prindle.xsh-239] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "asynchronous cancelation request" to "cancelation request". _____________________________________________________________________________ Page: 68 Line: 2391 Section: 3.8.9.2 Problem: The standard does not define "asynchronous cancelation request". The distinction between asynchronous and deferred applies only to the cancelability state, not to requests. This is a P1003.1n issue. Action: Change "asynchronous cancelation request" to "cancelation request". Shade and mark MAN. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 60 donn@interix.com BUG in XSH (rdvk# 272) [DT-XSH-29] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: leave as an XSI extension, remove the reviewers note _____________________________________________________________________________ Page: 76 Line: 2524 Section: Problem: (This is the first of several such objections, so I'll be longer here than elsewhere.) There are a number of functions introduced into the X/Open (and/or TOG) documents that were carefully considered and discarded in the original POSIX work as (excessively) redundant, dangerous, negative contributions to program portability, or the like. They appear to have crept back in to this document through the TOG draft, and again need to be discarded. There's little benefit in including antiquated, dangerous, or non-portable functions in a standard. All it does is make programs that aren't really that portable LOOK portable, without being particularly portable. This function, not even marked legacy, is one such function. Action: Delete section. _____________________________________________________________________________ Comment Enhancement Request Number 61 donn@interix.com BUG in XSH (rdvk# 273) [DT-XSH-30] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This was rejected as the proposed change is architecture specific _____________________________________________________________________________ Page: 81 Line: 2670 Section: a64l Problem: Be more precise; the current English adds nothing. Action: "is in the low-order 32 bits" -> "==x&0xffffffff". _____________________________________________________________________________ objection Enhancement Request Number 62 Frank Bug in XSH (rdvk# 16) [prindle.xsh-12] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: msg catalog descriptors should have stayed as an XSI extension (action: on AJ to check elsewhere) _____________________________________________________________________________ Page: 83 Line: 2693-2695 Section: abort() Problem: See also page 89, line 2969. See also page 175, line 5445-5447,5451,5453. See also page 250. NO ADDITIONAL PAGES WILL BE REPORTED HERE, BUT THIS REQUIRES A GLOBAL FIX. I cannot see how the reader should differentiate between margin code CX and margin code XSI. In these lines (marked CX) are extensions relating to fclose() [from POSIX] and extensions relating to message catalog descriptors [from UNIX]. It would appear that the latter extensions should be marked XSI to be consistent with such markings on page 89, line 2869. Similarly, the extensions on lines 2697-2698 and 3732-3733 do not appear to come from POSIX, yet they are marked CX. Also, see the curious mix of CX, XSI, and MAN on page 250, 266, etal. Action: Use CX margin code for all extensions to ANSI-C, regardless whether they came from POSIX or UNIX specs. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 63 donn@interix.com BUG in XSH (rdvk# 274) [DT-XSH-31] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is rejected since Application Usage is informative _____________________________________________________________________________ Page: 83 Line: 2702 Section: abort Problem: The observation about core files... if it's simply intended as an observation that's fine. However, this is potentially normative text, and is clearly phrased as normative text. Action: Either "a core dump may be produced" -> "some implementations produce core dumps", or move to a normative section. _____________________________________________________________________________ objection Enhancement Request Number 64 Frank Bug in XSH (rdvk# 15) [prindle.xsh-11] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The Man margin code will be added to the codes section as a reviewers note for the next draft. _____________________________________________________________________________ Page: 86 Line: 2787,2797-2800 Section: access() Problem: I reiterate as in prindle.xsh-5 that I have no clue what the margin designation MAN means. Here, MAN appears on each of the three error codes mentioned, one of which is mandatory and the other two of which are optional. So clearly, MAN has nothing to do with mandatory errors. Nor can I tell from the context of the particular error descriptions what the designation is supposed to mean. The best clue is perhaps on lines 2249-2250, but how is this different from XSI? Action: Define the meaning of margin code MAN in the codes section of 1.3. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 65 Frank Bug in XSH (rdvk# 237) [prindle.xsh-233] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add fdatasync() to the lists, as aio_fsync() may use either fsync() or fdatasync(). Shade and mark fdatasync() with margin code SIO _____________________________________________________________________________ Page: 95 Line: 3000,3005 Section: aio Problem: The function fdatasync() needs to be in these lists. This is a P1003.1n issue. Action: Add fdatasync() to the lists, as aio_fsync() may use either fsync() or fdatasync(). Shade and mark fdatasync() with margin code SIO|MAN. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 66 Frank Bug in XSH (rdvk# 239) [prindle.xsh-235] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 96 Line: 3065-3066 Section: aio Problem: This is a meaningless requirement. Remove it. This is a P1003.1n issue. Action: Delete these lines. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 67 donn@interix.com BUG in XSH (rdvk# 275) [DT-XSH-32] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is explicitly undefined. _____________________________________________________________________________ Page: 101 Line: 3208 Section: aio Problem: There's no explicit indicator that aio_return has been called with no status ready to retrieve. Action: Either: 1) Application usage section says how it should be coded to be sure that it doesn't return garbage. 2) Define a result that says it isn't ready. I slightly prefer the latter, but there may be good reasons for the former, which belong in the rationale. _____________________________________________________________________________ objection Enhancement Request Number 68 Frank Bug in XSH (rdvk# 238) [prindle.xsh-234] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "fails" to "may fail" _____________________________________________________________________________ Page: 101 Line: 3210 Section: aio Problem: This error code should be a may fail situation. Notice that it says this on line 3202. This is a P1003.1n issue. Action: Change "fails" to "may fail". Shade and mark MAN. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 69 Frank Bug in XSH (rdvk# 18) [prindle.xsh-14] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 104 Line: 3294-3296 Section: aio Problem: There is a slight screw-up in the shading and margin marking - the PIO marking appears to start one line too early. Action: Fix this to be like aio_read(). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 70 Frank Bug in XSH (rdvk# 19) [prindle.xsh-15] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 109 Line: 3483-3485 Section: asctime() Problem: This problem is right out of POSIX.1 - the format of the string returned by asctime_r() is not specified (i.e. any string would be conforming). Action: Replace "into a string" with "into a string (of the same form as that returned by asctime())" ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 71 Frank Bug in XSH (rdvk# 42) [prindle.xsh-38] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERANGE is defined in ISO C , so there is no action required. _____________________________________________________________________________ Page: 116 Line: 3642 Section: atan() Problem: See also asin(), atan2(), ceil(), cos(), fabs(), floor(), fmod(), sin(), tan(). Unfortunately, I don't have an ISO C handy, but do have several references to ANSI C. Are you sure ERANGE is an error defined for asin(), atan(), atan2(), ceil(), cos(), fabs(), floor(), fmod(), sin(), and tan() in ISO C? My references show ERANGE errors for some other functions (such as cosh() and exp()), but not these. Also, one ISO C reference I have says (regarding math function errors): "On a domain error, the function returns an implementation-defined value; whether the integer expression errno acquires the value EDOM is implementation-defined." Action: If ERANGE is defined for these functions in ISO C, I stand corrected. If not, shade these occurences of ERANGE as CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 72 donn@interix.com BUG in XSH (rdvk# 276) [DT-XSH-33] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The wording aligns with that in ISO C _____________________________________________________________________________ Page: 121 Line: 3727 Section: atexit Problem: Garbled. Action: "The atexit() function registers the function func (which will be called without arguments) to be called at normal process termination. Functions..." _____________________________________________________________________________ Objection Enhancement Request Number 73 donn@interix.com BUG in XSH (rdvk# 277) [DT-XSH-34] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: These are XSI functions. Their withdrawal is being phased thru LEGACY _____________________________________________________________________________ Page: 128,129 Line: 3919,3952 Section: bcmp,bcopy Problem: Discard historical junk (see _longjmp). Action: Discard. _____________________________________________________________________________ Objection Enhancement Request Number 74 donn@interix.com BUG in XSH (rdvk# 278) [DT-XSH-35] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is an XSI extension _____________________________________________________________________________ Page: 130 Line: 3988 Section: bsd Problem: I don't see a justification for this except pandering to the lowest common denominator. Action: Delete. _____________________________________________________________________________ Editorial Enhancement Request Number 75 donn@interix.com BUG in XSH (rdvk# 279) [DT-XSH-36] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the current text aligns with ISO C _____________________________________________________________________________ Page: 135 Line: 4144 Section: btowc Problem: Does it determine or convert? Action: It does both, but the sentences alternate between one or the other. Replace "The btowc() function determines..." with "The btowc() function attempts to convert c to it's wide-character form in the initial shift state, and returns WEOF if it determines that c is not a valid one-byte character in the initial shift state". (It seems likely to me that the original C standard text (I don't have a copy of the supplement) probably continued this sentence with something to the effect "and returns...". Inserting the RETURN VALUE section may have changed the meaning of the text.) _____________________________________________________________________________ editorial Enhancement Request Number 76 Frank Bug in XSH (rdvk# 20) [prindle.xsh-16] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 147 Line: 4509 Section: cfgetispeed() Problem: The rationale for this function appears in a later function, cfgetospeed(). There is also a wording error in the rationale in cfgetospeed(). Action: Move the rationale from cfgetospeed() here, and make the rationale section of each of the other 3 functions which follow say "Refer to cfgetispeed()." Also, when the rationale (which is on lines 4543-4569) is moved here, make the following fix: change "functions do not take numbers as arguments" to "functions do not take arguments as numbers". While not entirely correct (the get functions return the baud rate), at least it is readable and the reader knows what is really meant. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 77 donn@interix.com BUG in XSH (rdvk# 280) [DT-XSH-37] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The change history is informative and reflects what happened in the past. _____________________________________________________________________________ Page: 147 Line: 4521 Section: cfgetispeed Problem: I don't see what this change buys. If some other function can return a termios structure, great, say so. If not, then leaving it undefined is a good thing: this allows an implementation to look in several places to get the input speed without having to do extensive checking. (Don't overspecify the implementation.) Action: Drop (or justify). _____________________________________________________________________________ editorial Enhancement Request Number 78 Frank Bug in XSH (rdvk# 21) [prindle.xsh-17] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 150 Line: 4593 Section: cfsetispeed() Problem: Poor wording (not from POSIX, but then again its wording was poor also). Also on page 151, line 4634. Action: Change "on" to "with" on both line 4593 and line 4634. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 79 donn@interix.com BUG in XSH (rdvk# 281) [DT-XSH-38] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Leave existing text here for clarity. A new definition will be added to XBD (action HPA) _____________________________________________________________________________ Page: 154 Line: 4743 Section: chmod Problem: The material about S_ISVTX belongs in XBD under file access permissions, not here buried in a not particularly obvious place if you're looking for the effect, rather than the cause. Action: Move. _____________________________________________________________________________ Editorial Enhancement Request Number 80 donn@interix.com BUG in XSH (rdvk# 282) [DT-XSH-39] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 4902-4904 in rationale _____________________________________________________________________________ Page: 158 Line: 4888,4902 Section: chown Problem: Identical paragraphs. Action: Remove one (either). _____________________________________________________________________________ comment Enhancement Request Number 81 Frank Bug in XSH (rdvk# 22) [prindle.xsh-18] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept, delete all this rationale _____________________________________________________________________________ Page: 165 Line: 5088 Section: clock Problem: Yes, it is incorrect. Amazing that this rationale snuck in to even the 96 POSIX standard! Action: Remove this rationale. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 82 Frank Bug in XSH (rdvk# 24) [prindle.xsh-20] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add "If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified." (action on frank for the latter part of the proposed action below) _____________________________________________________________________________ Page: 166 Line: 5126-5127 Section: close() Problem: It is not clear what the state of fildes is if EIO is returned. Is a conforming implementation required to complete the close (deallocation) even if EIO is returned, or like so many other POSIX function, should the function have no effect if EIO is returned? In the very likely event that neither of these can be guaranteed, EIO should behave like EINTR. This should be addressed as a global problem wherever EIO can be returned. Action: Add "If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified." Globally check for EIO returns and see what effect this error has on semantics of functions which may return it. Generally, the occurence of this error should in some respects be treated as EINTR, since the operation may have done nothing, may have only partially completed, or may have completed to a large extent. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 83 donn@interix.com BUG in XSH (rdvk# 283) [DT-XSH-40] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: STREAMS pipes are discussed, see 5143- Its also an XSI extension _____________________________________________________________________________ Page: 166 Line: 5134 Section: close Problem: STREAMS pipes seem to be an implementation detail; it should be the case that "pipes are pipes" and discussing the implementation details of ones that choose to be implemented with STREAMS weakens the standard, because it introduces ambiguity in how to write an application. (This seems another "grab bag" feature.) Action: Remove this discussion. If a statement along the lines of "Pipes may be implemented on some systems so that bidirectional data movement is possible. Portable applications shall not use such a feature." is needed, that's fine. _____________________________________________________________________________ Editorial Enhancement Request Number 84 donn@interix.com BUG in XSH (rdvk# 284) [DT-XSH-41] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_85 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 167 Line: 5178,5184 Section: close Problem: Redundant paragraphs. Action: Delete one. _____________________________________________________________________________ editorial Enhancement Request Number 85 Frank Bug in XSH (rdvk# 23) [prindle.xsh-19] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 167 Line: 5184-5188 Section: close() Problem: These lines are duplicated under APPLICATION USAGE. Clearly the first paragraph belongs to APPLICATION USAGE. The second paragraph is really implementation guidance, so shouldn't be in APPLICATION USAGE. Action: Delete lines 5184-5185 (keep first paragraph in APPLICATION USAGE). Delete lines 5180-5182 (keep second paragraph in RATIONALE). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 86 Frank Bug in XSH (rdvk# 25) [prindle.xsh-21] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: At Austin/2 the decision was made to remove only. The OH marking is for XSI systems only _____________________________________________________________________________ Page: 179 Line: 5521 Section: creat() Problem: See also page 252, line 7764. See also page 640, line 20199. There may be others - consider this a global issue. Based on the definition of the margin code OH, I guess I don't understand the rationale for removing and keeping if neither is required by conforming systems. It certainly can't hurt to include or , but why keep here? In fact, what is the purpose of the OH code anyway? Same applies to before on pg 252 and before on pg 640. Action: Delete line 5521 and reflect this in the Issue 6 change history for creat(). Delete line 7764 and reflect this in the Issue 6 change history for fcntl(). Delete line 20199 and reflect this in the Issue 6 change history for open(). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 87 Frank Bug in XSH (rdvk# 26) [prindle.xsh-22] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change for the first action (must is ok) On the second action restore the use of shall as noted _____________________________________________________________________________ Page: 183 Line: 5615,5623 Section: ctermid() Problem: Elided "shall"; substitution of "must" for "shall" (applies to these lines and entire document). Personally, I like the "must" for an application requirement rather than an implementation requirement, but I'm not sure how ISO will take this. But "shall" is definitely missing in the second line. See also page 235, line 7253 (shall replaced by do). See also page 711, line 22127(shall be replaced by are). Elided or renamed "shall" is a very common bug throughout document; consequences range from minor to very serious, not even considering the ISO issue. Action: In POSIX first line reads "...function shall be called...", while here a "must" is used. I don't see a problem with this, as it differentiates between an appl. rqmt. and an impl. rqmt. But check with ISO style guidance on this. Also, else- where, shall is being used for application requirements. It might be simpler in the long run to keep the POSIX style and use shall for both. In POSIX, second line reads "The ctermid() function shall return". Restore this wording and scan POSIX.1 "shall"s to ensure that none are lost in this document where an implementation requirement is intended. Be especially careful where "shall" has been changed to "can", as this is very misleading. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 88 donn@interix.com BUG in XSH (rdvk# 285) [DT-XSH-42] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 188 Line: 5779 Section: dbm Problem: Clarity. Action: "is not replaced with the new record" -> "is left unchanged and the new record ignored". _____________________________________________________________________________ Objection Enhancement Request Number 89 donn@interix.com BUG in XSH (rdvk# 286) [DT-XSH-43] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to Application Usage "Since the meaning of leading // is implementation defined the dirname "//foo" could return either "//" or "/" and nothing else." _____________________________________________________________________________ Page: 192 Line: 5908 Section: dirname Problem: Assuming that the // convention is retained, this table (and the corresponding text) need to be explicit that // is treated differently from /. Action: Add line: "//foo" "//" _____________________________________________________________________________ Objection Enhancement Request Number 90 donn@interix.com BUG in XSH (rdvk# 289) [DT-XSH-46] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: refer to Base WG _____________________________________________________________________________ Page: 195 Line: 5984 Section: dlcolse Problem: A subsequent dlopen may have needed something this initially opened. Action: "are also closed" -> "are also closed if this is the last reference to it". _____________________________________________________________________________ Objection Enhancement Request Number 91 donn@interix.com BUG in XSH (rdvk# 287) [DT-XSH-44] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The is not just a PASC document. The project scope brings these functions in from the XSH specification. _____________________________________________________________________________ Page: 197 Line: 6031 Section: dlerror Problem: According to the PASC rules, the dl* functions (and others) MUST be renamed to be posix_dl*. Action: I expect that rule to be followed scrupulously throughout this process. I see no reason that new interfaces introduced via this process should be subject to any less onerous restrictions than new interfaces introduced via any other process. (Although the dl* functions are found on a number of systems, it's arguable whether they are in "wide industry use"; the same applies to a number of other new interface groups.) _____________________________________________________________________________ objection Enhancement Request Number 92 Frank Bug in XSH (rdvk# 28) [prindle.xsh-24] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: refer to the Base WG _____________________________________________________________________________ Page: 197 Line: 6033-6037 Section: dlerror() Problem: Given the semantics of this function, it clearly cannot be reentrant or thread- safe. Several threads may be manipulating different dl files, and each would be likely to clobber each other's error status (which could be fixed by passing the handle), not to mention the issue of several threads manipulating the same dl file while calling this function resets the error status (which would not be fixed by passing the handle). Action: Add the following to the description: "The dlerror() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." AND add dlerror() to the list of non-thread-safe functions on page 63, section 3.8.2. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 93 donn@interix.com BUG in XSH (rdvk# 288) [DT-XSH-45] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Rejected since the revision does not have such reinvention within its scope. _____________________________________________________________________________ Page: 197 Line: 6051 Section: dlerror Problem: (Somebody's got to be the bad guy on this one....) This is awful. Returning (unspecified) strings makes it effectively impossible for an application to do what recovery it might be able to do on the failure of dlopen and friends. The functions should return return error codes/flags like any reasonable function, and there should be a way to TRANSLATE those into meaningful strings for printing. (Imagine an application that wanted to say "I couldn't find this, where else should I look?": it would need to know that it was a lookup failure, not something else, before asking.) Action: Rewrite the whole function group to return error codes. Introduce a new function to translate to these strings. It should be possible to do that without breaking existing applications. (I'll take an action item as long as I'm not just wasting my time.) _____________________________________________________________________________ Objection Enhancement Request Number 94 donn@interix.com BUG in XSH (rdvk# 290) [DT-XSH-47] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: refer to Base WG _____________________________________________________________________________ Page: 198 Line: 6095 Section: dlopen Problem: Is "relocation" a defined concept? It's used heavily here, but without definition. If it's a "generally understood CS term", one of the dictionaries we refer to (of which I don't have copies) should define it. Action: If we can't find a supporting definition, I'll attempt one, but if we can, that would be better. _____________________________________________________________________________ Objection Enhancement Request Number 95 donn@interix.com BUG in XSH (rdvk# 291) [DT-XSH-48] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a section in DESCRIPTION that RTLD_NEXT is reserved (although also note that section 2 reserves the RTLD_ namespace) _____________________________________________________________________________ Page: 201 Line: 6206 Section: dlsym Problem: Reservation of symbol names is normative. This is in the Application Usage section (as noted earlier, that is frequently a problem). Action: Move the reservation (but not necessarily the explanation) to normative text. (Or move to Future Directions, and indicate that "it is likely".) _____________________________________________________________________________ Comment Enhancement Request Number 96 Andries.Brouwer@cwi.nl Bug in XSH (rdvk# 3) [dup2] Fri Jun 25, 3:21am +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206-207 Line: 6347,6383 Section: omitted Problem: Line 6383 contradicts line 6347. Action: Remove lines 6383-6384. _____________________________________________________________________________ comment Enhancement Request Number 97 Frank Bug in XSH (rdvk# 155) [prindle.xsh-151] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 210 Line: 6479 Section: encrypt() Problem: See also page 913 line 27970 section setkey(). See also page 1118 line 34146 section towctrans(). These function DESCRIPTIONS vary from the customary instruction about setting errno to zero before calling in order to test for failure. Action: Add some variation of the usual wording after this sentence, e.g.: An application wishing to check for error situations should set errno to 0 before calling encrypt(). If errno is non-zero on return, an error has occurred. In the case of towctrans(), these words need to be shaded and marked CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 98 donn@interix.com BUG in XSH (rdvk# 292) [DT-XSH-49] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_99 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 212 Line: 6516 Section: endgrent Problem: Some systems cannot enumerate the list of groups, either as an implementation detail or as a security issue. Action: Remove the interfaces, or at least specify that without appropriate privilege, that only some, or possibly no, groups are enumerated. Note: this was explicitly discussed and discarded in the original POSIX work (because of security considerations), and seems to have come back in the "grab bag" mode. _____________________________________________________________________________ objection Enhancement Request Number 99 Frank Bug in XSH (rdvk# 30) [prindle.xsh-26] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (restore these to XSI) _____________________________________________________________________________ Page: 212 Line: 6518-6521 Section: endgrent() Problem: Application usage section would indicate that these functions should be migrating toward legacy, not mandatory for conformance. It would seem to be counterproductive to include these under the POSIX umbrella when their usage is not recommended. The lack of a thread-safe alternative is also not consistent with POSIX. Also applies to: endpwent() and the 4 other referencing function pages. Action: Remove this note and do not make these mandatory. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 100 donn@interix.com BUG in XSH (rdvk# 293) [DT-XSH-50] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: These are in scope and will be left as XSI extensions. Delete the reviewers note on lines 6756-6759 _____________________________________________________________________________ Page: 214 Line: 6575 Section: endpwent Problem: As for endgrent(), remove. Action: Remove (family). _____________________________________________________________________________ Objection Enhancement Request Number 101 donn@interix.com BUG in XSH (rdvk# 294) [DT-XSH-51] Fri, 09 Jul 1999 09:19:07 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: These are in scope as XSI extensions _____________________________________________________________________________ Page: 216 Line: 6631 Section: endutxent Problem: This set of interfaces seems of very marginal use to portable applications (except possibly system accounting ones, which typically can't be portable for other reasons, anyway). It also probably introduces a security hole in that knowing who is logged in or not (at least accurately) is probably a security problem. Action: Either require appropriate privilege, or delete. _____________________________________________________________________________ objection Enhancement Request Number 102 Frank Bug in XSH (rdvk# 43) [prindle.xsh-39] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add a reviewers note that further CX markings need to be defined _____________________________________________________________________________ Page: 223 Line: 6783 Section: errno Problem: This is an ISO C interface, and needs the standard ISO C disclaimer. Action: Add after this line (shaded an margin coded CX): "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard are unintentional. This document defers to the ISO C standard." ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 103 Frank Bug in XSH (rdvk# 31) [prindle.xsh-27] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 225 Line: 6856-6859 Section: exec Problem: This text is dependent on the threads option. Action: Shade and mark this paragraph THR. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 104 H. Bug in XSH (rdvk# 435) Wed, 14 Jul 1999 13:31:29 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change to the spec. An action has been assigned to HPA to write a proposal and to submit it to the Base wg _____________________________________________________________________________ Page: 225 Line: 6862 Section: exec Problem: The so-called #!-hack is an expected feature of a modern Unix system, and is at the core of one of the very powerful features of the operating system: the seamless integration of various scripting languages. There are at least three ways of implementing the #!-hack: in the exec() functions of libc (usually only execve need to be modified since the other functions are usually implemented in terms of execve); in the kernel, exec server, or equivalent; or in /bin/sh. I believe it is overdue that this expected and essential feature is codified. The behaviour desired of the #!-hack is the following; this follows the behaviour of the existing systems. [[Issues that need to be discussed and should not be included in text are marked with double square brackets.]] [[For the sake of simplification, this discussion assumes execve() has been called, and that all other exec functions are implemented in terms of execve(). This is obviously not a requirement, and needs to be dealt with properly in the final text.]] If the file referenced by "path" exists, the current process has appropriate privileges, the length of the file is no less than two characters, and the first two characters of the file is the string "#!" then the content of the file will be parsed in the following manner: - The initial #! sequence and any following whitespace is skipped. - The next sequence of no more than {PATH_MAX} non-whitespace characters is stored as the "interpreter". - For the remainder of the line, any additional sequences of non-whitespace characters are individually stored as intrp_args[0..n-1] (for n == the number of such sequences. If there are no such sequences, n == 0.) [[Linux requires n <= 1. This causes problems with some existing scripts. Should we make the behaviour undefined if n > 1?]] If the line contains single or double quotation marks ('\'' or '\"') the behaviour is undefined. If the "interpreter" does not contain a leading '/', the behaviour is undefined. If the file begins with #! but the first line contains no non-whitespace characters, the file contains no '\n' character whatsoever, or the file referenced by "interpreter" does not exist, the behaviour is undefined. [[Should [ENOEXEC] be required here?]] If either the file referenced by "path" or the file referenced by "interpreter" has the set-user-ID or set-group-ID bit [[capability bits?]] set, the behaviour is undefined. [[There are two existing behaviours in use, and each has its advantages. Some systems honour the set-ID bits on the interpreter, others on the file, yet others on neither. Each variant has its advantages and drawbacks. Therefore it is probably not suitable for standardization, although one option would be to specify explicitly that each of these three alternatives are explicitly permitted.]] The argv array will then be modified in the following way: argv[0] is replaced with the basename of "interpreter" (using the same algorithm as basename().) [[Should it be permitted for argv[0] to simply be "interpreter"?]] argv[1] is replaced with the name of the file itself, as given by "path", except that if "path" lacks a leading '/', the current working directory is prepended, separated from '/' with slash characters as needed, thus making argv[1] independent of the current working directory. However, symlinks referenced in "path" shall not be canonicalized. argv[2..n+1] are replaced with intrp_args[0..n-1]. argv[n..n+m-2] are replaced with the original argv[1..m-1]. Finally, the file referenced by "interpreter" is invoked as the process image. If this file itself begins with #!, it is implementation-dependent if the result is to return [ENOEXEC] or the above process is recursed; otherwise the behaviour shall be as if execve() had been invoked directly using the above modified arguments. [[It may be preferrable to allow the return of [ENOEXEC] if the invocation of the interpreter would have returned [ENOENT].]] The #! issue is also described in XCU, where it is considered undefined. This needs to remain at least partially undefined, since kernel- and libc-based implementations will necessarily differ from shell-based implementations as to the behaviour of "sh script" where script starts with a legal #!-line with an interpreter *other* than "sh". However, it may be desirable to standardize the behaviour of the XCU shell encountering a #!-line which references itself. Action: This feature, and the lack thereof in the previous standard, is mentioned mentioned throughout the exec definition. The exec definition should be modified in all relevant places to incorporate the above described feature. _____________________________________________________________________________ objection Enhancement Request Number 105 Frank Bug in XSH (rdvk# 32) [prindle.xsh-28] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 226 Line: 6916 Section: exec Problem: This text is redundant and has the incorrect margin code. It is effectively repeated, with the correct margin code on lines 6924-6925 on the next page. Action: Remove this line. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 106 Frank Bug in XSH (rdvk# 33) [prindle.xsh-29] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 226 Line: 6917-6918 Section: exec Problem: Wrong margin code. Action: Change margin code from SHM to SEM. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 107 Frank Bug in XSH (rdvk# 34) [prindle.xsh-30] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 235 Line: 7245 Section: exit() Problem: