Document Number: AUSTIN/50 Title: XSHd3 Aardvark Change Request Report Revision Date: 2000-07-27 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XSH Draft 3. (for the avoidance of doubt this report supersedes the dispositions in the minutes) Aardvark Summary Table (XSHd3) ______________________ ERN 1 Duplicate of 263 ERN 2 Accept ERN 3 Accept ERN 4 Reject ERN 5 Accept ERN 6 Accept as marked ERN 7 Accept ERN 8 Accept ERN 9 Accept ERN 10 Reject ERN 11 Accept as marked ERN 12 Reject ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Accept ERN 17 Reject ERN 18 Accept ERN 19 Accept ERN 20 Accept as marked ERN 21 Reject ERN 22 Duplicate of 21 ERN 23 Accept as marked ERN 24 Accept ERN 25 Duplicate of 24 ERN 26 Accept ERN 27 Reject ERN 28 Accept ERN 29 Reject ERN 30 Accept ERN 31 Accept ERN 32 Reject ERN 33 Accept as marked ERN 34 Accept as marked ERN 35 Accept ERN 36 Accept as marked ERN 37 Accept as marked ERN 38 Reject ERN 39 Accept as marked ERN 40 Accept as marked ERN 41 Accept ERN 42 Accept as marked ERN 43 Accept ERN 44 Accept as marked ERN 45 Accept as marked ERN 46 Accept as marked ERN 47 Accept ERN 48 Accept ERN 49 Accept ERN 50 Accept ERN 51 Accept as marked ERN 52 Accept ERN 53 Accept as marked ERN 54 Accept as marked ERN 55 Accept ERN 56 Accept as marked ERN 57 Accept as marked ERN 58 Accept as marked ERN 59 Accept as marked ERN 60 Accept as marked ERN 61 Accept ERN 62 Accept as marked ERN 63 Accept as marked ERN 64 Accept ERN 65 Accept as marked ERN 66 Accept ERN 67 Accept as marked ERN 68 Accept as marked ERN 69 Accept ERN 70 Accept as marked ERN 71 Accept as marked ERN 72 Accept as marked ERN 73 Reject ERN 74 Reject ERN 75 Accept as marked ERN 76 Accept ERN 77 Accept ERN 78 Accept ERN 79 Accept ERN 80 Accept ERN 81 Accept as marked ERN 82 Accept as marked ERN 83 Reject ERN 84 Accept ERN 85 Accept ERN 86 Accept as marked ERN 87 Accept as marked ERN 88 Accept as marked ERN 89 Accept as marked ERN 90 Accept as marked ERN 91 Accept as marked ERN 92 Reject ERN 93 Reject ERN 94 Accept as marked ERN 95 Accept as marked ERN 96 Accept ERN 97 Accept as marked ERN 98 Accept as marked ERN 99 Accept as marked ERN 100 Reject ERN 101 Accept as marked ERN 102 Accept as marked ERN 103 Reject ERN 104 Duplicate of 105 ERN 105 Accept ERN 106 Reject ERN 107 Accept ERN 108 Duplicate of 107 ERN 109 Accept as marked ERN 110 Accept ERN 111 Accept ERN 112 Accept as marked ERN 113 Accept as marked ERN 114 Accept as marked ERN 115 Accept ERN 116 Reject ERN 117 Accept ERN 118 Accept as marked ERN 119 Accept as marked ERN 120 Accept ERN 121 Accept as marked ERN 122 Accept as marked ERN 123 Accept ERN 124 Accept as marked ERN 125 Accept as marked ERN 126 Accept as marked ERN 127 Accept as marked ERN 128 Accept as marked ERN 129 Reject ERN 130 Accept as marked ERN 131 Accept as marked ERN 132 Accept as marked ERN 133 Accept as marked ERN 134 Accept as marked ERN 135 Accept as marked ERN 136 Reject ERN 137 Accept as marked ERN 138 Accept as marked ERN 139 Accept ERN 140 Reject ERN 141 Reject ERN 142 Accept as marked ERN 143 Reject ERN 144 Accept ERN 145 Accept as marked ERN 146 Accept ERN 147 Accept ERN 148 Accept ERN 149 Accept ERN 150 Reject ERN 151 Accept ERN 152 Accept as marked ERN 153 Accept ERN 154 Accept ERN 155 Accept as marked ERN 156 Accept as marked ERN 157 Accept as marked ERN 158 Accept Accept as marked ERN 159 Accept ERN 160 Reject ERN 161 Accept as marked ERN 162 Accept ERN 163 Accept as marked ERN 164 Accept as marked ERN 165 Accept ERN 166 Accept as marked ERN 167 Accept as marked ERN 168 Accept as marked ERN 169 Accept ERN 170 Accept as marked ERN 171 Accept as marked ERN 172 Accept ERN 173 Accept as marked ERN 174 Accept as marked ERN 175 Accept ERN 176 Accept as marked ERN 177 Accept as marked ERN 178 Accept as marked ERN 179 Accept ERN 180 Accept as marked ERN 181 Accept as marked ERN 182 Accept as marked ERN 183 Accept ERN 184 Accept as marked ERN 185 Accept ERN 186 Accept ERN 187 Accept ERN 188 Accept ERN 189 Accept ERN 190 Accept ERN 191 Accept ERN 192 Accept ERN 193 Accept ERN 194 Accept ERN 195 Accept ERN 196 Accept ERN 197 Accept ERN 198 Accept ERN 199 Accept ERN 200 Accept as marked ERN 201 Accept ERN 202 Accept ERN 203 Accept ERN 204 Accept as marked ERN 205 Accept as marked ERN 206 Accept as marked ERN 207 Accept as marked ERN 208 Accept ERN 209 Accept as marked ERN 210 Reject ERN 211 Reject ERN 212 Reject ERN 213 Accept ERN 214 Accept ERN 215 Accept as marked ERN 216 Accept as marked ERN 217 Accept ERN 218 Accept ERN 219 Accept ERN 220 Accept as marked ERN 221 Accept ERN 222 Accept ERN 223 Accept ERN 224 Accept ERN 225 Accept ERN 226 Accept ERN 227 Accept ERN 228 Accept ERN 229 Accept as marked ERN 230 Duplicate of 229 ERN 231 Accept ERN 232 Accept ERN 233 Reject ERN 234 Accept ERN 235 Accept ERN 236 Accept ERN 237 Accept ERN 238 Accept ERN 239 Accept as marked ERN 240 Accept as marked ERN 241 Duplicate of 242 ERN 242 Accept ERN 243 Duplicate of 242 ERN 244 Accept ERN 245 Accept ERN 246 Accept ERN 247 Accept ERN 248 Accept as marked ERN 249 Accept as marked ERN 250 Accept ERN 251 Accept ERN 252 Accept ERN 253 Accept ERN 254 Accept ERN 255 Accept ERN 256 Accept as marked ERN 257 Accept ERN 258 Accept ERN 259 Accept ERN 260 Accept ERN 261 Accept as marked ERN 262 Accept as marked ERN 263 Accept ERN 264 Accept as marked ERN 265 Accept as marked ERN 266 Accept ERN 267 Accept as marked ERN 268 Accept ERN 269 Accept ERN 270 Accept ERN 271 Accept ERN 272 Accept ERN 273 Accept ERN 274 Accept ERN 275 Accept ERN 276 Accept ERN 277 Accept ERN 278 Accept ERN 279 Accept ERN 280 Accept ERN 281 Accept ERN 282 Accept as marked ERN 283 Accept ERN 284 Accept ERN 285 Accept ERN 286 Accept ERN 287 Accept as marked ERN 288 Accept ERN 289 Accept ERN 290 Accept as marked ERN 291 Reject ERN 292 Accept as marked ERN 293 Accept ERN 294 Accept as marked ERN 295 Reject ERN 296 Reject ERN 297 Accept as marked ERN 298 Reject ERN 299 Reject ERN 300 Accept as marked ERN 301 Accept as marked ERN 302 Reject ERN 303 Accept as marked ERN 304 Reject ERN 305 Duplicate of 306 ERN 306 Accept ERN 307 Accept ERN 308 Accept as marked ERN 309 Accept as marked ERN 310 Reject ERN 311 Reject ERN 312 Accept ERN 313 Accept as marked ERN 314 Accept ERN 315 Accept as marked ERN 316 Reject ERN 317 Accept as marked ERN 318 Accept ERN 319 Accept ERN 320 Accept as marked ERN 321 Accept as marked ERN 322 Accept ERN 323 Accept as marked ERN 324 Accept ERN 325 Accept as marked ERN 326 Accept as marked ERN 327 Accept as marked ERN 328 Accept ERN 329 Accept ERN 330 Accept as marked ERN 331 Reject ERN 332 Accept ERN 333 Accept ERN 334 Accept ERN 335 Accept ERN 336 Accept ERN 337 Accept ERN 338 Accept ERN 339 Accept ERN 340 Accept ERN 341 Accept ERN 342 Accept ERN 343 Accept ERN 344 Accept as marked ERN 345 Accept as marked ERN 346 Accept ERN 347 Accept as marked ERN 348 Accept ERN 349 Accept ERN 350 Accept ERN 351 Accept ERN 352 Reject ERN 353 Accept as marked ERN 354 Accept ERN 355 Accept as marked ERN 356 Accept as marked ERN 357 Accept ERN 358 Accept ERN 359 Accept as marked ERN 360 Accept ERN 361 Accept as marked ERN 362 Accept ERN 363 Accept ERN 364 Accept ERN 365 Duplicate of 364 ERN 366 Accept ERN 367 Reject ERN 368 Accept as marked ERN 369 Accept ERN 370 Accept ERN 371 Accept ERN 372 Accept as marked ERN 373 Reject ERN 374 Accept ERN 375 Accept as marked ERN 376 Accept as marked ERN 377 Accept ERN 378 Accept as marked ERN 379 Accept as marked ERN 380 Accept as marked ERN 381 Accept as marked ERN 382 Accept as marked ERN 383 Accept as marked ERN 384 Accept ERN 385 Accept as marked ERN 386 Accept as marked ERN 387 Accept as marked ERN 388 Accept ERN 389 Accept ERN 390 Accept as marked ERN 391 Accept ERN 392 Accept ERN 393 Reject ERN 394 Accept as marked ERN 395 Accept ERN 396 Accept ERN 397 Accept ERN 398 Accept ERN 399 Accept ERN 400 Accept ERN 401 Accept ERN 402 Accept ERN 403 Accept as marked ERN 404 Accept as marked ERN 405 Accept ERN 406 Accept as marked ERN 407 Accept as marked ERN 408 Accept as marked ERN 409 Accept ERN 410 Accept as marked ERN 411 Reject ERN 412 Accept as marked ERN 413 Accept as marked ERN 414 Accept as marked ERN 415 Accept ERN 416 Accept ERN 417 Accept as marked ERN 418 Accept as marked ERN 419 Accept as marked ERN 420 Accept ERN 421 Accept as marked ERN 422 Accept ERN 423 Accept as marked ERN 424 Accept as marked ERN 425 Accept as marked ERN 426 Accept as marked ERN 427 Duplicate of 426 ERN 428 Accept ERN 429 Duplicate of 428 ERN 430 Accept ERN 431 Accept ERN 432 Accept ERN 433 Accept as marked ERN 434 Accept ERN 435 Accept as marked ERN 436 Accept ERN 437 Accept as marked ERN 438 Accept as marked ERN 439 Accept ERN 440 Accept ERN 441 Accept ERN 442 Accept as marked ERN 443 Accept as marked ERN 444 Accept ERN 445 Duplicate of 444 ERN 446 Accept ERN 447 Accept as marked ERN 448 Accept as marked ERN 449 Accept as marked ERN 450 Accept ERN 451 Accept as marked ERN 452 Accept ERN 453 Accept ERN 454 Accept ERN 455 Accept ERN 456 Accept as marked ERN 457 Accept as marked ERN 458 Accept ERN 459 Accept as marked ERN 460 Accept ERN 461 Accept as marked ERN 462 Accept ERN 463 Accept ERN 464 Accept ERN 465 Accept as marked ERN 466 Reject ERN 467 Accept ERN 468 Accept as marked ERN 469 Accept ERN 470 Accept ERN 471 Accept ERN 472 Reject ERN 473 Accept ERN 474 Reject ERN 475 Accept as marked ERN 476 Accept as marked ERN 477 Accept as marked ERN 478 Accept as marked ERN 479 Reject ERN 480 Accept ERN 481 Accept as marked ERN 482 Reject ERN 483 Accept as marked ERN 484 Accept ERN 485 Accept as marked ERN 486 Accept ERN 487 Accept as marked ERN 488 Accept as marked ERN 489 Accept as marked ERN 490 Reject ERN 491 Accept ERN 492 Accept as marked ERN 493 Accept ERN 494 Accept as marked ERN 495 Accept as marked ERN 496 Accept ERN 497 Accept ERN 498 Accept as marked ERN 499 Accept as marked ERN 500 Accept as marked ERN 501 Accept ERN 502 Accept as marked ERN 503 Accept as marked ERN 504 Accept ERN 505 Accept as marked ERN 506 Reject ERN 507 Accept ERN 508 Reject ERN 509 Reject ERN 510 Accept as marked ERN 511 Reject ERN 512 Reject ERN 513 Accept ERN 514 Accept ERN 515 Accept as marked ERN 516 Accept ERN 517 Accept as marked ERN 518 Accept as marked ERN 519 Accept as marked ERN 520 Accept ERN 521 Accept as marked ERN 522 Accept as marked ERN 523 Accept ERN 524 Accept ERN 525 Accept ERN 526 Accept ERN 527 Accept ERN 528 Reject ERN 529 Reject ERN 530 Accept ERN 531 Accept ERN 532 Duplicate of 531 ERN 533 Reject ERN 534 Accept ERN 535 Accept ERN 536 Accept ERN 537 Reject ERN 538 Accept ERN 539 Accept ERN 540 Accept ERN 541 Accept ERN 542 Accept ERN 543 Accept ERN 544 Accept ERN 545 Accept ERN 546 Accept ERN 547 Accept as marked ERN 548 Accept as marked ERN 549 Accept ERN 550 Accept as marked ERN 551 Accept as marked ERN 552 Accept ERN 553 Accept ERN 554 Accept as marked ERN 555 Accept as marked ERN 556 Reject ERN 557 Accept ERN 558 Accept as marked ERN 559 Accept ERN 560 Accept ERN 561 Accept as marked ERN 562 Accept ERN 563 Accept ERN 564 Accept ERN 565 Accept ERN 566 Accept ERN 567 Accept ERN 568 Accept ERN 569 Accept ERN 570 Accept ERN 571 Accept ERN 572 Accept ERN 573 Accept as marked ERN 574 Accept ERN 575 Accept ERN 576 Accept ERN 577 Accept ERN 578 Accept ERN 579 Accept ERN 580 Accept ERN 581 Accept ERN 582 Accept ERN 583 Accept ERN 584 Accept ERN 585 Accept ERN 586 Accept ERN 587 Accept ERN 588 Accept ERN 589 Accept ERN 590 Accept ERN 591 Accept ERN 592 Accept as marked ERN 593 Accept ERN 594 Accept ERN 595 Accept ERN 596 Accept ERN 597 Accept as marked ERN 598 Reject ERN 599 Accept as marked ERN 600 Accept ERN 601 Accept as marked ERN 602 Accept as marked ERN 603 Accept ERN 604 Accept as marked ERN 605 Accept as marked ERN 606 Accept as marked ERN 607 Accept ERN 608 Accept ERN 609 Accept ERN 610 Reject ERN 611 Accept ERN 612 Accept ERN 613 Accept ERN 614 Reject ERN 615 Accept as marked ERN 616 Accept as marked ERN 617 Accept ERN 618 Accept ERN 619 Accept ERN 620 Accept as marked ERN 621 Accept as marked ERN 622 Accept as marked ERN 623 Reject ERN 624 Accept ERN 625 Reject ERN 626 Reject ERN 627 Reject ERN 628 Reject ERN 629 Accept ERN 630 Accept ERN 631 Reject ERN 632 Accept ERN 633 Accept ERN 634 Accept ERN 635 Accept ERN 636 Accept ERN 637 Accept as marked ERN 638 Accept ERN 639 Accept ERN 640 Accept ERN 641 Accept ERN 642 Accept ERN 643 Accept ERN 644 Accept ERN 645 Accept ERN 646 Accept ERN 647 Accept ERN 648 Accept ERN 649 Accept ERN 650 Accept ERN 651 Accept ERN 652 Accept ERN 653 Accept ERN 654 Accept ERN 655 Accept ERN 656 Accept ERN 657 Accept ERN 658 Accept ERN 659 Accept ERN 660 Accept ERN 661 Accept ERN 662 Accept ERN 663 Accept ERN 664 Accept as marked ERN 665 Accept ERN 666 Accept ERN 667 Accept ERN 668 Accept ERN 669 Accept ERN 670 Accept ERN 671 Accept ERN 672 Accept ERN 673 Accept ERN 674 Reject ERN 675 Reject ERN 676 Accept as marked ERN 677 Accept as marked _____________________________________________________________________________ editorial Enhancement Request Number 1 pete.forman@westgeo.com Bug in XSHd3 (rdvk# 15) {PWF20000411} Tue, 11 Apr 2000 09:27:00 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_263 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: The Issue 6 notes state that the epoch that was explicit in previous issues was January 1 1980. That year should be 1970. This typo is present in several functions: ftime(), getdate(), gettimeofday(). Epoch is correctly defined in XBD 3.151 as being in 1970. Action: Change "1980" to "1970" in the pages for ftime(), getdate(), and gettimeofday(). _____________________________________________________________________________ Editorial Enhancement Request Number 2 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 617) [DWC-28] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: (structure element references) References to C-language structure elements (such as aiocbp->aio_nbytes on P122, L4004) need to use the C-language operator "->"; not an arrow symbol. Action: Globally change all arrow symbols in this draft used to join a structure pointer to an element of the associated structure to use the string "->" instead. ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 3 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 390) {drb-7} Fri, 14 Apr 2000 19:11:21 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: getsockopt Problem: Since the release of 1003.1c, the PASC Interpretations committee has determined that a number of "issues" raised for interpretation were errors in the base standard. It had been the intent of the working group that these issues be incorporated into 1003.1n as a "corrigenda to 1003.1c". However the initial draft of 1003.1n omitted most of these issues and XSH6D3 therefore retains the original errors. Rather than try to compile a list all at once, I plan to report each bug separately as I get to it, with this paragraph as a common header. Some sections of POSIX 1003.1c-1995 failed to specify that a SIGPIPE signal should always be delivered to the thread that attempts to read from a pipe (or, in SUS, a socket). This was an editing omission, leaving the original word "process". The response to POSIX interpretation request #47 confirms that it was the intent of the working group that SIGPIPE be delivered to the thread, and recommends that the standard be changed. While the POSIX functions in XSH6D3 have already been fixed, a FIND for SIGPIPE revealed several omissions in the non-POSIX parts: (page 82, line 2807, 2.10.6 "Socket Types"): "A SIGPIPE signal is raised if a process sends on a broken stream". (page 84, line 2912, 2.10.14 "Signals"): "The SIGPIPE signal shall be sent to a process that attempts to send data [...]". (page 539, line 17074, getsockopt): description of SO_KEEPALIVE flag, "processes writing to the socket are notified with a SIGPIPE signal". (page 1176, line 35883, send): "[EPIPE] [...] the SIGPIPE signal is generated to the calling process". (page 1178, line 35969, sendmsg): "[EPIPE] [...] the SIGPIPE signal is generated to the calling process". (page 1181, line 36075, sendto): "[EPIPE] [...] the SIGPIPE signal is generated to the calling process". (page 1219, line 36975, setsockopt): description of SO_KEEPALIVE flag, "processes writing to that socket are notified with a SIGPIPE signal". Action: In each case, the word "process" should be replaced by the word "thread". (And the word "processes" on page 539 is of course replaced by the word "threads" ;-) ) _____________________________________________________________________________ Comment Enhancement Request Number 4 donnte@microsoft.com Bug in XSHd3 (rdvk# 433) [DT-XSH-1] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The style is consistent, even if not always obvious. The amount of work required to reorganize is not felt to be worth the benefit and will make the draft less consistent. Use of pointer pages is intended to help, so if you look for random you get a pointer to initstate, in the electronic html version you get the right page and they are hard linked . _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: The use of the alphabetically first of a group of functions is becoming more and more counterintuitive. Use the alphabetically first "meaningful" name (e.g., in the case of random, random, not the not-obviously-related initstate). In particular, having all the close_xxx functions come first is really odd. (This would also tend to even the document out more.) Action: Select the name used as the primary key for a group of functions to be a "primary" (and hopefully intuitive) name rather than the alphabetically first such name. _____________________________________________________________________________ objection Enhancement Request Number 5 prindle@voicenet.com Bug in XSHd3 (rdvk# 667) [prindle.xsh-37] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: All Line: All Section: All Problem: Throughout this draft, the qualifying phrase (for assertions which are not true unless an option is supported) takes on two distinctly different and inconsistent forms: If is defined... and If the option is supported... Specific instances of this problem occurs on page 1412, at lines 42854, 42858, and 42860, but it occurs numerous other places as well. The document should be consistent in the way in which this is handled. In particular, since the whole issue of how options relate to the definition and/or value of compile-time symbols, and how they relate to the values returned by sysconf() is rather ill-defined at this time across the entire set of options (see [prindle.xbd-1]), the more suitable form is the second (using the option name and the word supported) because it is independent from how support for the option is indicated; this was determined to be the preferrable solution many years ago by the SSWG-RT working group. Action: Change all occurrences of "If is defined" to "If the option is supported". ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 6 donnte@microsoft.com Bug in XSHd3 (rdvk# 434) [DT-XSH-2] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Move scope, references and conformance to XBD. Add new Introduction subsection, explaining that this is a volume of the entire standard, and cross referencing XBD for scope, normative references and conformance clauses. Merge scopes from XSH and XCU into a single section. _____________________________________________________________________________ Page: 1 Line: 12 Section: 1.1 Problem: This scope statement needs to be rewritten, at least to delete item 1 (which is now addressed in another volume). Action: Delete item 1; move/merge this scope statement to XBD. _____________________________________________________________________________ Comment Enhancement Request Number 7 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 618) [DWC-29] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 34-35 Section: 1.1 Problem: (Scope) The last sentence in this paragraph: "The facilities provided support a convenient function for writing multi- threaded applications." does not appear in POSIX.1-1996 and is not true. (There is no function like posix_write_multithreaded_app().) Action: Delete the last sentence on P1, L34-35. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 8 donnte@microsoft.com Bug in XSHd3 (rdvk# 435) [DT-XSH-3] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 4 Line: 58 Section: 1.3 Problem: Should the general references be consolidated into XBD? Action: Consider a single set of references in XBD, referenced here if need be. _____________________________________________________________________________ Editorial Enhancement Request Number 9 donnte@microsoft.com Bug in XSHd3 (rdvk# 436) [DT-XSH-4] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Revision bars will not appear in the final standard. _____________________________________________________________________________ Page: 7 Line: 131 Section: 1.5 Problem: Revision bar mess. Action: Fix. _____________________________________________________________________________ Comment Enhancement Request Number 10 donnte@microsoft.com Bug in XSHd3 (rdvk# 437) [DT-XSH-5] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is not a sub-option of XSI, but an additional option to the ISO standard. _____________________________________________________________________________ Page: 21 Line: 616 Section: 1.9 Problem: XSR appears to be a sub-option of XSI. It should be described as such. Action: Add: This is not part of the ISO standard contained in this document, but rather part of the XSI feature set that has been added to it. (Similarly for XSH and XBD.) _____________________________________________________________________________ Editorial Enhancement Request Number 11 donnte@microsoft.com Bug in XSHd3 (rdvk# 438) [DT-XSH-6] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete lines 676-686 _____________________________________________________________________________ Page: 25 Line: 674 Section: 2 Problem: This simply repeats the table of contents. Action: Delete. _____________________________________________________________________________ Objection Enhancement Request Number 12 donnte@microsoft.com Bug in XSHd3 (rdvk# 439) [DT-XSH-7] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the reviewers believe the behavior is the same and the sentence is correct as is (i.e. do not believe problem statement). _____________________________________________________________________________ Page: 28 Line: 771 Section: 2.2 Problem: This isn't true... if _XOPEN_SOURCE is defined as 600, then additional namespace pollution (OK, features) are introduced, thus the behavior is NOT the same. Action: Add to end of sentence beginning "Therefore...": ", except that certain additional XSI features are introduced into the namespace." _____________________________________________________________________________ objection Enhancement Request Number 13 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 362) [tog-c99-xsh 336] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 32 Line: 914-944 Section: 2.2 Problem: Change required for alignment with C99. Action: Add the following identifiers to the table on lines 914-944: _Exit acosh acoshf acoshl acosl asinh asinhf asinhl asinl atanf atanh atanh atanhf atanhl atanl atoll cabs cabsf cabsl cacos cacosf cacosh cacoshf cacoshl cacosl carg cargf cargl casin casinf casinh casinhf casinhl casinl catan catanf catanh catanh catanhf catanhf catanhl catanhl catanl cbrt cbrtf cbrtl ccos ccosf ccosh ccoshf ccoshl ccosl ceilf ceill cexp cexpf cexpl cimag cimagf cimagl clog clogf clogl conj conjf conjl copysign copysignf copysignl cpow cpowf cpowl cproj cprojf cprojl creal crealf creall csin csinf csinh csinhf csinhl csinl csqrt csqrtf csqrtl ctan ctanf ctanl erfcf erfcl erff erfl exp2 exp2f exp2l expm1 expm1f expm1l fdim fdimf fdiml feclearexcept fegetenv fegetexceptflag fegetround feholdexcept feraiseexcept fesetenv fesetexceptflag fesetround fetestexcept feupdateenv fma fmaf fmal fmax fmaxf fmaxl fmin fminf fminl hypotf hypotl ilogb ilogbf ilogbl imaxabs imaxdiv isblank iswblank ldiv lgammaf lgammal llabs llrint llrintf llrintl llround llroundf llroundl log1p log1pf log1pl log2 log2f log2l logb logbf logbl lrint lrintf lrintl lround lroundf lroundl nan nanf nanl nearbyint nearbyintf nearbyintl nextafterf nextafterl nexttoward nexttowardf nexttowardl remainderf remainderl remquo remquof remquol rint rintf rintl round roundf roundl scalbln scalblnf scalblnl scalbn scalbnf scalbnl strtof strtoimax strtold strtoll strtoull strtoumax tgamma tgammaf tgammal trunc truncf truncl vfscanf vfwscanf vscanf vsscanf vswscanf vwscanf wcstof wcstoimax wcstold wcstoll wcstoull wcstoumax _____________________________________________________________________________ objection Enhancement Request Number 14 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 363) [tog-c99-xsh 337] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 33 Line: 955-980 Section: 2.2 Problem: Change required for alignment with C99. Action: Remove the following identifiers from the table on line 955-980. These functions are now defined in C99 and should no longer be marked XSI: acosh asinh atanh expm1 ilogb log1p logb rint The XSI markings should also be removed from the associated man page entries in section 3. _____________________________________________________________________________ editorial Enhancement Request Number 15 Antoine.Leca@renault.fr Bug in XSHd3 (rdvk# 23) {al-01} Tue, 18 Apr 2000 12:51:31 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 38 Line: 1149 Section: Error Problem: EDOM and ERANGE are described as "(defined in the ISO C standard)." EILSEQ too is described by this standard. Action: Add "(defined in the ISO C standard)." at the end of the description of EILSEQ. _____________________________________________________________________________ Objection Enhancement Request Number 16 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 619) [DWC-30] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 39 Line: 1195-1196 Section: 2.3 Problem: (ENAMETOOLONG errors with _POSIX_NO_TRUNC) Since POSIX.1a aligned with FIPS requirements and the FIPS required _POSIX_NO_TRUNC to always be defined, a lot of text referring to _POSIX_NO_TRUNC should have been removed from this draft. Action: Delete " and _POSIX_NO_TRUNC was in effect for that file" from P39, L1195- 1196. ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 17 drepper@redhat.com Bug in XSHd3 (rdvk# 405) {ud-36} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: Withdrawn by originator _____________________________________________________________________________ Page: 43 Line: 1369 Section: Signal Problem: The text in the fourth paragraph of section 2.4.1 differs from the POSIX text. Mostly these are improvements but one thing is formulated not as good. In the lines 1369ff the drafts says: [...] or the action associated with the signal is set to ignore the signal. [...] This could be interpreted as if ignoring the signal in a single thread is enough. But this cannot be the intention. At least my assumption is that the signal must be ignored in all threads before it can be ignored for the process. Action: Replace lines 1369ff with of the signal, or the action associated with the signal is set for all threads to ignore the signal. If the action associated with a blocked signal is to ignore the signal for all threads and if that signal is generated for the process, it is unspecified whether the signal is discarded immediately upon generation or remains pending. _____________________________________________________________________________ Editorial Enhancement Request Number 18 donnte@microsoft.com Bug in XSHd3 (rdvk# 440) [DT-XSH-8] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 43 Line: 1382 Section: 2.4 Problem: should "in circumstances" be shaded. Action: Shade it. _____________________________________________________________________________ Comment Enhancement Request Number 19 donnte@microsoft.com Bug in XSHd3 (rdvk# 441) [DT-XSH-9] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 46 Line: 1480 Section: 2.4.2 Problem: Do as noted. Action: _____________________________________________________________________________ Objection Enhancement Request Number 20 donnte@microsoft.com Bug in XSHd3 (rdvk# 442) [DT-XSH-10] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add reviewers note to p49 line 1605 to note the discrepancy and await the interp. _____________________________________________________________________________ Page: 48 Line: 1592 Section: 2.4.8 Problem: Conflict with subsequent text. At 1592, there's the "with a single exception clause". At 1605 in the sentence beginning with "If" would seem to disallow that exception. Action: Replace the sentence with a pointer to the discussion of signal-safe and unsafe functions. _____________________________________________________________________________ comment Enhancement Request Number 21 drepper@redhat.com Bug in XSHd3 (rdvk# 403) {ud-37} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Historic practice _____________________________________________________________________________ Page: 50 Line: 1642-1644 Section: Standard Problem: In section 2.5 the draft contains a reviewers note about stderr. I would prefer a different resolution of the ERN. stderr should really be used only for writing. In most cases fd 2 is opened with O_WRONLY. Why allowing reading by this wording? If it is decided that reading must be possible leave this implementation defined. It is better (and possibly safer) to open the descriptor only for writing and this should be allowed. The current wording would declare such a system non-conforming. Action: Replace the proposed wording with "stderr is opened for output." Possibly (if really necessary) add "Whether the stream allows reading is implementation defined." _____________________________________________________________________________ Comment Enhancement Request Number 22 donnte@microsoft.com Bug in XSHd3 (rdvk# 443) [DT-XSH-11] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_21 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 50 Line: 1644 Section: 2.5 Problem: Make the change. Action: _____________________________________________________________________________ comment Enhancement Request Number 23 drepper@redhat.com Bug in XSHd3 (rdvk# 402) {ud-38} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "shall be" on 1656 to "is". Mark all of 2.5.1 CX remove the first reviewers note _____________________________________________________________________________ Page: 51 Line: 1653 Section: Standard Problem: The reviewers note at the top of section 2.5.1 asks for shading. The answer is to shade the whole section. File descriptors, fork() etc do not appear in ISO C and the handling is therefore an extension. Action: Add shading with label CX for the whole section and remove the first reviewers note. _____________________________________________________________________________ Comment Enhancement Request Number 24 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 620) [DWC-31] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1664-1668 Section: 2.5.1 Problem: (Interaction of File Descriptors and Standard I/O Streams) I believe the current text on P51, L1669-1671 is clearer than the proposed replacement. Action: Delete the Notes to Reviewers on P51, L1664-1668 and leave the text on P51, L1669-1671 unchanged. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 25 donnte@microsoft.com Bug in XSHd3 (rdvk# 444) [DT-XSH-12] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_24 Reject_____ Rationale for rejected or partial changes: (note the new text here would add additional questions) _____________________________________________________________________________ Page: 51 Line: 1666 Section: 2.5.1 Problem: Make the change. Action: Do it. _____________________________________________________________________________ comment Enhancement Request Number 26 drepper@redhat.com Bug in XSHd3 (rdvk# 404) {ud-39} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 53 Line: 1731 Section: Standard Problem: The standard should not refer to amendment 1 of ISO C90 but instead to ISO C99. Action: Replace first sentence in section 2.5.2 with For conformance to the ISO/IEC 9899:1999, the definition [...] _____________________________________________________________________________ Objection Enhancement Request Number 27 donnte@microsoft.com Bug in XSHd3 (rdvk# 445) [DT-XSH-13] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: this standard provides APIs, not advice on how to write drivers. cf write() does not tell you how to write data to a disk, nor send() how to write the TCP/IP protocol layers. _____________________________________________________________________________ Page: 55 Line: 1666 Section: 2.5.1 Problem: Although a lot of the "wrapper" information about STREAMS modules is defined, nothing is said about how to actually write a STREAMS module. I don't know enough about STREAMS to know if sufficient information is there by implication, although it might be. However, I don't find anything here about how to create such a beast. As it stands, it appears that there's "secret information" (at least with respect to formal standards) required to actually use this stuff. Action: If I'm wrong, then an example of how to write, create, and use a STREAMs module (say, one that does character translation such as toupper) would be very useful. If I'm right (and I think I am) then add the necessary information (including some implementation-defined hand-waves if compiler options are needed) (NOT unspecified, implementation-defined, please!) and the example. (Or..., just delete STREAMS.) _____________________________________________________________________________ Editorial Enhancement Request Number 28 donnte@microsoft.com Bug in XSHd3 (rdvk# 446) [DT-XSH-14] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 61 Line: 1991 Section: 2.8.2 Problem: Delete comma. Action: "aio_filedes, and" -> "aio_filedes and". _____________________________________________________________________________ Objection Enhancement Request Number 29 donnte@microsoft.com Bug in XSHd3 (rdvk# 447) [DT-XSH-15] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Out of scope; this text appears in the original standard, so cannot be deleted. Need some suggested text to add ... _____________________________________________________________________________ Page: 61 Line: 1996 Section: 2.8.2 Problem: The text here, as is (permitting relaxation of ordering requirements on MP systems) puts an unreasonable burden on the application. Since there doesn't seem to be a way to determine even IF an application is running on a MP system, how is the application supposed to cope with the problem. Action: Either delete this exception, or add text telling the application how to cope with it portably. _____________________________________________________________________________ Comment Enhancement Request Number 30 donnte@microsoft.com Bug in XSHd3 (rdvk# 448) [DT-XSH-16] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 63 Line: 2091 Section: 2.8.3 Problem: Use new text. Action: Use new text. _____________________________________________________________________________ Objection Enhancement Request Number 31 donnte@microsoft.com Bug in XSHd3 (rdvk# 449) [DT-XSH-17] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 68 Line: 2306 Section: 2.8.5 Problem: EMB (As described in XCU, this notes and embarrassing error.) "shall be implementation-dependent". Huh? Action: -> "is implementation-defined". _____________________________________________________________________________ Objection Enhancement Request Number 32 donnte@microsoft.com Bug in XSHd3 (rdvk# 450) [DT-XSH-18] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The reviewers did not see any ambiguity here. _____________________________________________________________________________ Page: 68 Line: 2307 Section: 2.8.5 Problem: "maximum" here can be read equally well as "largest numerically" or "finest grained" (smallest numerically). Action: Change "maximum" to either "poorest" or "largest allowable granularity". _____________________________________________________________________________ Comment Enhancement Request Number 33 donnte@microsoft.com Bug in XSHd3 (rdvk# 451) [DT-XSH-19] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete harmonization bullet. Move 2345 to top of section. Add phrase "This section is not further shaded for this option". (also shaded) _____________________________________________________________________________ Page: 70 Line: 2351 Section: 2.9 Problem: Hasn't this harmonization occurred already? Also... the whole section should be shaded. Action: Shade 2.9, delete "Harmonization..." bullet point. _____________________________________________________________________________ objection Enhancement Request Number 34 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 12) {drb-1} Fri, 7 Apr 2000 18:36:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add Note to say "While a read from a pipe of PIPE_MAX*2 bytes may not generate a single atomic and thread-safe stream of bytes, it should generate "several" (individually atomic) thread-safe streams of bytes. Similiarly, while reading from a terminal device may not generate a single atomic and thread-safe stream of bytes, it should generate some finite number of (individually atomic) and thread-safe streams of bytes. That is, concurrent calls to read for a pipe, FIFO, or terminal device are not allowed to result in corrupting the stream of bytes or other internal data. However, read(), in these cases, is not required to return a single contiguous and atomic stream of bytes." Also, add "socket" (after FIFO) to the list of read() non-thread-safe exceptions on line 2442 _____________________________________________________________________________ Page: 72 Line: 2442 Section: 2.9.2 Problem: XSH6D3 states that "The read() function need not be thread-safe when reading from a pipe, FIFO, or terminal device." This is incorrect and would make a large number of existing programs illegal. (And, worse, would validate broken operating systems that do not support these applications.) According to the definitions of SUS, being "not thread-safe" means that the function (there is no allowance in the definition for a restricted scope of unsafety, such as "concurrent calls using the same file descriptor") cannot be called concurrently from multiple threads. This would essentially render read() unusable in threaded programs. What we have here, I believe from the explanations garnered off the austin-group list, is a misunderstanding in 1003.1a of the full ramifications of "thread-safety". It has been correctly pointed out that POSIX already states that a read of greater than PIPE_MAX bytes from a FIFO or pipe is not atomic, and in general terminal reads are also not atomic. This phrase was intended to reflect these realities. Unfortunately, that's not what it does. There is a difference between "thread-safe" and "atomic". While a read from a pipe of PIPE_MAX*2 bytes may not generate a single atomic and thread-safe stream of bytes, it should generate "several" (individually atomic) thread-safe streams of bytes. Similiarly, while reading from a terminal device may not generate a single atomic and thread-safe stream of bytes, it should generate some finite number of (individually atomic) and thread-safe streams of bytes. That is, concurrent calls to read for a pipe, FIFO, or terminal device are not allowed to result in corrupting the stream of bytes or other internal data. However, read, in these cases, is not required to return a single contiguous and atomic stream of bytes. This is much like the case of the stdio functions, where successive calls to getchar(), though thread-safe, may result in non-contiguous characters. (Another thread may read or write between the two calls.) The stdio package solves this problem by providing explicit interfaces to lock (flockfile) and unlock (funlockfile) the stdio stream so that the sequence of getchar() calls will be "atomic" as well as "thread safe". The warning here is of ORDERING anomalies, not DATA CORRUPTION. Such a warning is valid, but does not belong in this section. Action: REMOVE line 2442. Instead, in the description of the read() function, explain that 1) A read() of more than PIPE_MAX bytes from a pipe or FIFO will not necessarily return a contiguous set of bytes from the input device. Some intermediate bytes may have been returned to other threads concurrently reading from the device. 2) A read() from a terminal device will not necessarily return a contiguous set of bytes from the input device. Some intermediate bytes may have been returned to other threads concurrently reading from the device. Furthermore, if this is true for read(), I expect it would also be the case for write(), and similar warnings should be added to the write() page. _____________________________________________________________________________ comment Enhancement Request Number 35 drepper@redhat.com Bug in XSHd3 (rdvk# 406) {ud-40} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 73 Line: 2494 Section: Threads Problem: With the introduction of pthread_mutex_timedlock this list is incomplete. Action: Add as line 2494: * It returns successfully from pthread_mutex_timedwait() with m as the mutex argument. The list item must be shaded appropriately with TMO. _____________________________________________________________________________ Comment Enhancement Request Number 36 donnte@microsoft.com Bug in XSHd3 (rdvk# 452) [DT-XSH-20] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: new text for line 2771 "Selecting a protocol involves specifiying the protocol family, socket type, and protocol number to the socket() function." _____________________________________________________________________________ Page: 81 Line: 2772 Section: 2.10.2 Problem: The use of the word "create" here seems confusing. I suspect it's referring to two different means of creating a socket. However, as it reads it simply says "do it by creating it or by creating it", which sounds simply dumb. Action: Socket guys... what's intended? _____________________________________________________________________________ objection Enhancement Request Number 37 nick@usenix.org Bug in XSHd3 (rdvk# 19) {Usenix5} Thu, 13 Apr 2000 03:20:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: An action item is outstanding. Once the action item is submitted a new rdvk request should be submitted for D4 _____________________________________________________________________________ Page: 82 Line: 2794- Section: socket Problem: There is no SOCK_RAW type described here, even optionally. I believe that such a socket type is described in the newly approved IEEE Std 1003.1g. Action: Add all SOCK_RAW functionality from 1003.1g to this document. _____________________________________________________________________________ comment Enhancement Request Number 38 drepper@redhat.com Bug in XSHd3 (rdvk# 407) {ud-41} Wed, 26 Apr 2000 05:13:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the only mandatory functionality is that the symbol must be defined. _____________________________________________________________________________ Page: 82 Line: 2809 Section: Sockets Problem: Should everything concerning the SOCK_SEQPACKET socket type be available only with a new profile? Since I don't think that a many implementations are handling this socket type it will be necessary to allow existing implementations to be standard compliant. Action: Lots of places in the text from XNS have to be shaded. I haven't done this now since first a decision has to be made. _____________________________________________________________________________ Objection Enhancement Request Number 39 donnte@microsoft.com Bug in XSHd3 (rdvk# 453) [DT-XSH-21] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to "transfer only as much as is available." _____________________________________________________________________________ Page: 82 Line: 2836 Section: 2.10.7 Problem: It would appear that we're requiring nonblocking IO to ALWAYS transfer less than requested. If read VERY careful, it's correct, but it's not immediately obvious. (And, as noted below, it might not always be true!) Action: "transfer less than requested" -> "transfer as much as is available, which may be less than the amount requested". (I can imagine a protocol that would block until a termination condition occurred and then satisfy a read, but not return until that termination occurred even if there is enough data to satisfy the read. Thus it would be possible to return a full count in a situation which would otherwise block.) _____________________________________________________________________________ Objection Enhancement Request Number 40 donnte@microsoft.com Bug in XSHd3 (rdvk# 454) [DT-XSH-22] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to X-refs to 2.10.17 - 2.10.19 as that information is included _____________________________________________________________________________ Page: 84 Line: 2916 Section: 2.10.14 Problem: "annex for each protocol"... Wuzzat? I presume it's something in the original POSIX stuff that's not made it here. Action: Either remove or regain the spirit from the original stuff. _____________________________________________________________________________ Objection Enhancement Request Number 41 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 621) [DWC-32] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 93 Line: 3257-3258 Section: 2.11 Problem: (Data Types: posix_typed_mem_info) The posix_typed_mem_info structure is not a data type and should not appear in this table. The only types that should appear are types defined by typedef. There is no requirement in the rest of this draft that specifies a typedef for posix_typed_mem_info; it is just the tag of a structure. Action: Delete P93, L3257-3258. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 42 donnte@microsoft.com Bug in XSHd3 (rdvk# 455) [DT-XSH-23] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: There has already been substantial discussion on new legacy for earlier drafts, and a call was made in March 1999. These functions were not on that list. They are used extensively. However, the app usage does suggest that they should become legacy at some time. Therefore, update FUTURE DIRECTIONS to say that these *may* be marked legacy in a future revision. _____________________________________________________________________________ Page: 98 Line: 3350 Section: _longjmp Problem: This statement would suggest that _longjmp (etc.) be marked legacy. Action: Mark _longjmp (etc.) legacy. _____________________________________________________________________________ Editorial Enhancement Request Number 43 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 622) [DWC-33] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 103 Line: 3447 Section: a64l Problem: (a64l,l64a: inconsistent character quoting) The second paragraph of the description of a64l() and l64a() uses quoted characters to specify the characters used to represent digits except for 0 and 9. Action: Change "0 through 9 for 2-11" on P103, L3447 to "'0' through '9' for 2-11". ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 44 donnte@microsoft.com Bug in XSHd3 (rdvk# 456) [DT-XSH-24] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add "This is not the same encoding as used by either encoding variant of the uuencode utility" to Rationale. Add uuencode to See Also. _____________________________________________________________________________ Page: 103 Line: 3447 Section: a64l Problem: What is the relationship here to uuencode (both flavors)? Action: After 3462 add: This is not the same encoding as used by either variant of the uuencode command. Add "SEE ALSO" to uuencode in XCU. _____________________________________________________________________________ Objection Enhancement Request Number 45 donnte@microsoft.com Bug in XSHd3 (rdvk# 457) [DT-XSH-25] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: reword the XSI variant to remove the common things, and list only the addition of message catalog desciptors, so "In addition..." _____________________________________________________________________________ Page: 105 Line: 3497 Section: abort Problem: EMB Except for the XSI qualification, the text on 3497 and 3499 is the same. Action: Delete paragraph at 3499. _____________________________________________________________________________ Comment Enhancement Request Number 46 donnte@microsoft.com Bug in XSHd3 (rdvk# 458) [DT-XSH-26] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace ", and..." with " then the actions associates with SIGABRT defined in 2.4.1 are taken." _____________________________________________________________________________ Page: 105 Line: 3516 Section: abort Problem: The rest of the document is careful to avoid discussion core dumps, we should be consistent. Action: Replace ", and..." with " then the actions associates with SIGABRT defined in 2.4.1 will be taken." _____________________________________________________________________________ objection Enhancement Request Number 47 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 243) [tog-c99-xsh 217] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 98 Line: 12709-12711 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "int fscanf(FILE * stream, const char * format, ... ); int scanf(const char * format, ... ); int sscanf(const char * s, const char * format, ... );" To: "int fscanf(FILE * restrict stream, const char * restrict format, ... ); int scanf(const char * restrict format, ... ); int sscanf(const char * restrict s, const char * restrict format, ... );" [Ed note: Add to CH The prototypes for fscanf(), scanf() and sscanf() are updated for for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Editorial Enhancement Request Number 48 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 623) [DWC-34] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108,...,1443 Line: 3578,...,43842 Section: accept,...,tzset Problem: (extraneous spaces in synopses) There is an extraneous space between the name of the function and the opening parenthesis in the synopsis line for a few functions in this draft. Action: Change "accept (int" on P108, L3578 to "accept(int". Change "crypt (const" on P223, L7065 to "crypt(const". Change "expm1 (double" on P295, L9334 to "expm1(double". Change "getuid (void);" on P546, L17334 to "getuid(void);". Change "*hsearch (ENTRY" on P560, L17776 to "*hsearch(ENTRY". Change "ilogb (double" on P577, L18248 to "ilogb(double". Change "log1p (double" on P685, L21525 to "log1p(double". Change "rand (void);" on P1071, L32284 to "rand(void);". Change "tzset (void);" on P1443, L43842 to "tzset(void);". This list was created by performing a visual grep. Please check for any other occurrences of this problem and fix any I missed as well. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 49 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 624) [DWC-35] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110,181 Line: 3668-3670,5707-5709 Section: access,chdir Problem: (ELOOP errors) The ELOOP errors are fine as listed. The requirements as stated here are that ELOOP shall be reported if there is a symbolic link loop, but implementations are allowed to report an ELOOP error if {SYMLOOP_MAX} links were encountered while resolving a pathname even if a loop hasn't been confirmed at that point. Action: Delete P110, L3668-3670. Delete P181, L5707-5709. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 50 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 625) [DWC-36] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 110,...,1469 Line: 3674,...,44641 Section: access,...,utimes Problem: (ENAMETOOLONG errors with _POSIX_NO_TRUNC) See also my objection with label DWC-30. Since POSIX.1a aligned with FIPS requirements and the FIPS required _POSIX_NO_TRUNC to always be defined, a lot of text referring to _POSIX_NO_TRUNC should have been removed from this draft. (Most notably, ENAMETOOLONG error descriptions of the form: The length of the path argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX} while _POSIX_NO_TRUNC is in effect. should be changed to: The length of path exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. with obvious changes needed when the argument is not named path, and when more than one argument undergoes pathname resolution.) These changes have been made in several places, but there are dozens of places where it has not been done. There are also a few places where typographical errors have crept into the changes. Action: On P110, L3674-3676; P181, L5713-5715; P184-185, L5813-5815; P188, L5955- 5958; P362, L11489-11492; P427, L13698-13699; P718, L22558-22560; P721, L22654-22656; P800, L25075-25077; P1125, L34200-34202; P1304, L39498-39500; P1457, L44231-44233; P1466, L44547-44549; and P1469, L44639-44641 change the description of the ENAMETOOLONG from: The length of the path argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX} while _POSIX_NO_TRUNC is in effect. to: The length of the path argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Make the same change to P1087, L32988-32989. (A typographical error make the current text very different from the above, but the fix is the same.) Make the same change to P1433, L43564-43566. (The current text is different from the above, but the fix is the same.) Change P281, L8827-8830 to: The length of the path or file argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P352, L11117-11118 and P392, L12571-12573 to: The length of the filename argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P662, L20787-20788 to: The length of the path or path2 argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P754, L23770-23772; P765, L24064-24065; P878, L27298-27300; P1153, L35138-35140; P1161, L35345-35346; P1230, L37332-37334; and P1233, L37433- 37434 to: The length of the name argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P806, L25284-25286 to: The length of the dirname argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P1093, L33140-33142 to: The length of the file_name argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P1116, L33921-33923 to: The length of the old or new argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX}. Change P1365, L41411-41414 to: The length of the path2 argument exceeds {PATH_MAX} or a path name component is longer than {NAME_MAX} or the length of the path1 argument is longer than {SYMLINK_MAX}. (Note that this also changes "pname" to "path1"; there is no "pname" argument to the symlink() function.) ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 51 donnte@microsoft.com Bug in XSHd3 (rdvk# 459) [DT-XSH-27] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: leave the section, it is useful rationale. Change "taken back out" --> "is not included". on line 3713 _____________________________________________________________________________ Page: 111 Line: 3709 Section: access Problem: This paragraph is ancient history. Action: Remove. Lacking that, at least change 3714 to "an earlier version of this standard", as it never was in the 200x version! _____________________________________________________________________________ objection Enhancement Request Number 52 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 74) [tog-c99-xsh 50] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 113 Line: 3753 Section: acos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Add after line 3753: float acosf(float x); long double acosl(long double x); [Ed note: Add to CH The acosf() and acosl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 53 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 75) [tog-c99-xsh 51] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The acos( ) function ..." To "The acos(), acosf() and acosl() functions ..." Same change on lines 3770 and 3772. _____________________________________________________________________________ Page: 113 Line: 3758 Section: acos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Change "The acos( ) function ..." To "The acos family of functions ..." Same change on lines 3770 and 3772. _____________________________________________________________________________ objection Enhancement Request Number 54 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 76) [tog-c99-xsh 52] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "Upon successful completion, acos( ) ..." To "Upon successful completion, the acos(), acosf() and acosl() functions ..." _____________________________________________________________________________ Page: 113 Line: 3763 Section: acos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Change "Upon successful completion, acos( ) ..." To "Upon successful completion, the acos family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 55 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 95) [tog-c99-xsh 71] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3800-3802 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1-3). Action: Change "double acosh(double x); double asinh(double x); double atanh(double x);" To "double acosh(double x); float acoshf(float x); long double acoshl(long double x); double asinh(double x); float asinhf(float x); long double asinhl(long double x); double atanh(double x); float atanhf(float x); long double atanhl(long double x);" [Ed note: Add to CH The acoshf(), acoshl(), asinhf(), asinhl(), atanhf() and atanhl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 56 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 96) [tog-c99-xsh 72] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The acosh( ) function ..." To "The acosh(), acoshf() and acoshl() functions ..." _____________________________________________________________________________ Page: 115 Line: 3810 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1). Action: Change "The acosh( ) function ..." To "The acosh family functions ..." _____________________________________________________________________________ objection Enhancement Request Number 57 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 97) [tog-c99-xsh 73] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The atanh( ) function ..." To "The atanh(), atanhf() and atanhl() functions ..." _____________________________________________________________________________ Page: 115 Line: 3812 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 58 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 98) [tog-c99-xsh 74] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The acosh( ) function ..." To "The acosh(), acoshf() and acoshl() functions ..." _____________________________________________________________________________ Page: 115 Line: 3817 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1). Action: Change "The acosh( ) function ..." To "The acosh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 59 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 99) [tog-c99-xsh 75] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The atanh( ) function ..." To "The atanh(), atanhf() and atanhl() functions ..." _____________________________________________________________________________ Page: 115 Line: 3819 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 60 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 100) [tog-c99-xsh 76] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The atanh( ) function ..." To "The atanh(), atanhf() and atanhl() functions ..." _____________________________________________________________________________ Page: 115 Line: 3821 Section: acosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 61 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 77) [tog-c99-xsh 53] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 136 Line: 4437 Section: asin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Add after line 4437: float asinf(float x); long double asinl(long double x); [Ed note: Add to CH The asinf() and asinl() are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 62 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 78) [tog-c99-xsh 54] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The asin( ) function ..." To "The asin(), asinf() and asinl() of functions ..." Same change on lines 4455 and 4457. _____________________________________________________________________________ Page: 136 Line: 4442 Section: asin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Change "The asin( ) function ..." To "The asin family of functions ..." Same change on lines 4455 and 4457. _____________________________________________________________________________ objection Enhancement Request Number 63 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 79) [tog-c99-xsh 55] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "Upon successful completion, asin( ) ..." To "Upon successful completion, the asin(), asinf(), asinl() of functions ..." _____________________________________________________________________________ Page: 136 Line: 4447 Section: asin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Change "Upon successful completion, asin( ) ..." To "Upon successful completion, the asin family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 64 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 25) [tog-c99-xsh 1] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 139 Line: 4494 Section: assert Problem: Change required for alignment with C99 (ref C99 section 7.2.1.1) Action: Change "void assert(int expression);" To "void assert(scalar expression);" [Ed note: Add to CH The prototype for the expression argument to assert is changed from int to scalar for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 65 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 26) [tog-c99-xsh 2] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The assert( ) macro inserts diagnostics into programs. When it is executed, if expression is false (that is, compares equal to 0), assert( ) writes information about the particular call that failed (including the text of the argument, the name of the source file, and the source file line numberthe latter are respectively the values of the preprocessing macros __FILE__ and __LINE__) on stderr and calls abort()." To "The assert( ) macro inserts diagnostics into programs; it expands to a void expression. When it is executed, if expression (which shall have a scalar type) is false (that is, compares equal to 0), assert( ) shall write information about the particular call that failed on stderr and shall call abort(). The information written about the call that failed shall include the text of the argument, the name of the source file, the source file line number, and the name of the enclosing function, the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__ and of the identifier __func__. " Add to Change history: The DESCRIPTION of assert() is updated for alignment with ISO/IEC 9899:1999 C. _____________________________________________________________________________ Page: 139 Line: 4499-4503 Section: assert Problem: Change required for alignment with C99 (ref C99 section 7.2.1.1) Action: Change "The assert( ) macro inserts diagnostics into programs. When it is executed, if expression is false (that is, compares equal to 0), assert( ) writes information about the particular call that failed (including the text of the argument, the name of the source file, and the source file line numberthe latter are respectively the values of the preprocessing macros __FILE__ and __LINE__) on stderr and calls abort()." To "The assert( ) macro inserts diagnostics into programs; it exapnds to a void expression. When it is executed, if expression (which shall have a scalar type) is false (that is, compares equal to 0), assert( ) writes information about the particular call that failed (including the text of the argument, the name of the source file, the source file line number, and the name of the enclosing function the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__ and of the identifier __func__) on stderr and calls abort()." _____________________________________________________________________________ objection Enhancement Request Number 66 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 80) [tog-c99-xsh 56] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 140 Line: 4530 Section: atan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Add after line 4530: float atanf(float x); long double atanl(long double x); _____________________________________________________________________________ objection Enhancement Request Number 67 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 81) [tog-c99-xsh 57] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The atan( ) function ..." To "The atan(), atanf() and atanl() functions ..." Same change on line 4544. _____________________________________________________________________________ Page: 140 Line: 4535 Section: atan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Change "The atan( ) function ..." To "The atan family of functions ..." Same change on line 4544. _____________________________________________________________________________ objection Enhancement Request Number 68 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 82) [tog-c99-xsh 58] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "Upon successful completion, atan( ) ..." To "Upon successful completion, the atan(), atanf() and atanl() functions ..." _____________________________________________________________________________ Page: 140 Line: 4539 Section: atan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Change "Upon successful completion, atan( ) ..." To "Upon successful completion, the atan family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 69 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 83) [tog-c99-xsh 59] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 142 Line: 4574 Section: atan2 Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Add after line 4574: float atan2f(float y, float x); long double atan2l(long double y, long double x); _____________________________________________________________________________ objection Enhancement Request Number 70 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 84) [tog-c99-xsh 60] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The atan2( ) function ..." To "The atan2(), atan2f(), atan2l() functions ..." _____________________________________________________________________________ Page: 142 Line: 4579 Section: atan2 Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Change "The atan2( ) function ..." To "The atan2 family of functions ..." Same change on line 4590. _____________________________________________________________________________ objection Enhancement Request Number 71 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 85) [tog-c99-xsh 61] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "Upon successful completion, atan2( ) ..." To "Upon successful completion, the atan2(), atan2f(), atan2l() functions ..." _____________________________________________________________________________ Page: 142 Line: 4584 Section: atan2 Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Change "Upon successful completion, atan2( ) ..." To "Upon successful completion, the atan family of functions ..." _____________________________________________________________________________ Objection Enhancement Request Number 72 donnte@microsoft.com Bug in XSHd3 (rdvk# 460) [DT-XSH-28] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use the words suggested. CX shade the phrase about "in the reverse order". Replace the whole paragraph at 4633 with: "The atexit() function registers the function pointed to by func, to be called without arguments at normal program termination. At normal program termination, all functions registered by the atexit function shall be called, [CX] in the reverse order of their registration. [CX off] Normal termination occurs either by a call to exit() or a return from main()." _____________________________________________________________________________ Page: 145 Line: 4633 Section: atexit Problem: See old ERN #72. The current text is garbled, as I said last time. My proposed text was rejected on the grounds that the current text aligns with ISO C. At least in my copy, it does NOT exactly align with ISO C. ISO C's wording, although in my opinion still suboptimal, is at least clear. Restore something closer to the ISO C wording. (Some of the existing changes to the ISO wording are not objectionable to me, but are also unnecessary.) Action: Replace the whole paragraph at 4633 with: "The atexit() function registers the function pointed to by func, to be called without arguments at normal program termination. At normal program termination, all functions registered by the atexit function shall be called, in the reverse order of their registration. Normal termination occurs either by a call to exit() or a return from main()." _____________________________________________________________________________ Objection Enhancement Request Number 73 donnte@microsoft.com Bug in XSHd3 (rdvk# 461) [DT-XSH-29] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Part of ISO C and ISO C is adding more of these functions .... _____________________________________________________________________________ Page: 147 Line: 4686 Section: atof Problem: A good case for Legacy. Action: Mark atof as legacy. _____________________________________________________________________________ Objection Enhancement Request Number 74 donnte@microsoft.com Bug in XSHd3 (rdvk# 462) [DT-XSH-30] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: (also see 73) ISO C is adding more of these functions .... _____________________________________________________________________________ Page: 148 Line: 4735 Section: atoi Problem: Another case for legacy. Action: Mark atoi legacy. _____________________________________________________________________________ objection Enhancement Request Number 75 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 267) [tog-c99-xsh 241] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add after line 4756: long long atoll(const char *nptr); Add to CH the atoll() function is added for alignment with ISO/IEC 9899:1999 C _____________________________________________________________________________ Page: 150 Line: 4756 Section: atoll Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Add after line 4756: long long int atoll(const char *nptr); _____________________________________________________________________________ objection Enhancement Request Number 76 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 268) [tog-c99-xsh 242] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 150 Line: 4762 Section: atoll Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Add after line 4762: The call atoll(str) shall be equivalent to: strtoll(nptr, (char **)NULL, 10) _____________________________________________________________________________ objection Enhancement Request Number 77 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 269) [tog-c99-xsh 243] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 150 Line: 4766 Section: atoll Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Change "The atol() function shall return ..." To "The atol() and atoll() functions shall return ..." _____________________________________________________________________________ objection Enhancement Request Number 78 drepper@redhat.com Bug in XSHd3 (rdvk# 3) {ud-11} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 151 Line: 4794 Section: basename() Problem: The review note for basename says: It is recommended that basename() and dirname() become mandatory, as POSIX.2 includes counterpart utilities. This is no good reason. The tools can be implemented with existing functions already. The main reason I object is because the definition of basename() as in this and prior drafts is so horribly broken by design. The in-place modification is on most cases where this function can be used unwanted. Also, not being thread-safe does not improve the usability. Another reason: there is widespread common practice to use a completely different definition for this function which is much more useful in normal situations. An implementation for this function would be as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ char * basename (filename) const char *filename; { char *p = strrchr (filename, '/'); return p ? p + 1 : (char *) filename; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The difference is that this function does not handle trailing / characters in the same way and the input string "/" is also handled differently. I very strongly object against including this definition of basename() in the POSIX standard. I know it has to be in the XPG but that's about it. glibc provides the XPG variant of basename as well as above variant, with the latter being the default. If this IMO completely broken design would get adopted for POSIX this would disqualify glibc from being compliant since we cannot and will not change the default. Action: Remove the review note and keep basename as an XSI extension. _____________________________________________________________________________ Objection Enhancement Request Number 79 donnte@microsoft.com Bug in XSHd3 (rdvk# 463) [DT-XSH-31] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 151 Line: 4804 Section: basename Problem: This does not discuss "//". In general, the command and the function should be reconciled to do the same thing. Add the command to the SEE ALSO section. Action: Add text "If the string is exactly "//" is is implementation defined whether "/" or "//" is returned." Add basename command to See Also section. _____________________________________________________________________________ editorial Enhancement Request Number 80 drepper@redhat.com Bug in XSHd3 (rdvk# 4) {ud-12} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 154 Line: 4903 Section: bcopy() Problem: This is really only for perfectionest. The text currently says: For maximum portability, it is recommended to replace the function call to bcopy() as follows: #define bcopy(b1,b2,len) memmove((b2), (b1), (size_t)(len)) Beside that I don't understand why there is this cast to size_t (memmove also takes a size_t parameter) this definition alters the bcopy functionality and might lead people who actually use bcopy() but on a system with memmove() to not notice some problems. Action: A better definition would be: #define bcopy(b1,b2,len) (memmove((b2), (b1), (len)), (void) 0) This way also the return value is appropriately defined. _____________________________________________________________________________ Objection Enhancement Request Number 81 donnte@microsoft.com Bug in XSHd3 (rdvk# 464) [DT-XSH-32] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The socket in use" to "The socket specified by (italics on)socket (italics off)"... _____________________________________________________________________________ Page: 155 Line: 4933 Section: bind Problem: There may be several sockets in use... be more precise. Action: "The socket in use" -> "The socked specified by _socket_"... _____________________________________________________________________________ Objection Enhancement Request Number 82 donnte@microsoft.com Bug in XSHd3 (rdvk# 465) [DT-XSH-33] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This will be marked as obsolescent. _____________________________________________________________________________ Page: 157 Line: 5026 Section: bsd_signal. Problem: The very reason for the creation of this function is that it's inherently a legacy function. Its only purpose is to allow old applications to run, and if that's not legacy, then what is? Action: Mark legacy. _____________________________________________________________________________ Objection Enhancement Request Number 83 donnte@microsoft.com Bug in XSHd3 (rdvk# 466) [DT-XSH-34] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: (after lots of discussion!) this would open up other holes (such as the conversion of EOF). Lots of controversy. This change would reduce concensus. _____________________________________________________________________________ Page: 162 Line: 5156 Section: btowd Problem: See ERN #75 The first (content containing) sentence of the the page says that btowc determines (and ONLY determines) if a character is a valid one byte character. It later adds (in RETURN VALUE) "oh, and it converts it too." (From the initial description, you'd conclude it was a boolean function.) I looked at c98 (I don't have the Amendment) and I agree that the C standard has the same problem... it doesn't describe the function accurately at the beginning. Notwithstanding that... it's misleading. Action: Add at 5157: "and if so returns the corresponding wide character." _____________________________________________________________________________ editorial Enhancement Request Number 84 drepper@redhat.com Bug in XSHd3 (rdvk# 5) {ud-13} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 163 Line: 5195 Section: bzero() Problem: This is the equivalent of my request ud-12 but this time for bzero. Action: A better definition would be: #define bzero(b,len) (memset((b), '\0', (len)), (void) 0) This way also the return value is appropriately defined. Another nit: I normally prefer to write the second parameter of memset() as a character to signal this is a single byte an only an int because of the default promotion. _____________________________________________________________________________ objection Enhancement Request Number 85 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 27) [tog-c99-xsh 3] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 163 Line: 5207 Section: cacos Problem: Change required for alignment with C99 (ref C99 section 7.3.5.1). Action: Add the following entry after line 5207: NAME cacos - complex arc cosine functions SYNOPSIS #include double complex cacos(double complex z); float complex cacosf(float complex z); long double complex cacosl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cacos family of functions shall compute the complex arc cosine of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The cacos family of functions shall return the complex arc cosine value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [0, pi] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ccos(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 86 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 33) [tog-c99-xsh 9] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 163 Line: 5207 Section: cacosh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.1). Action: Add the following entry after line 5207: NAME cacosh - complex arc hyperbolic cosine functions SYNOPSIS #include double complex cacosh(double complex z); float complex cacoshf(float complex z); long double complex cacoshl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cacosh family of functions shall compute the complex arc hyperbolic cosine of z, with a branch cut at values less than 1 along the real axis. RETURN VALUE The cacosh family of functions shall return the complex arc hyperbolic cosine value, in the range of a half-strip of non-negative values along the real axis and in the interval [-ipi, +ipi] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ccosh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 87 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 145) [tog-c99-xsh 121] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 165 Line: 5267 Section: cbrt Problem: Change required for alignment with C99 (ref C99 section 7.12.7.1). Action: Add the following entry after line 5267: NAME cbrt - cube root functions SYNOPSIS #include double cbrt(double x); float cbrtf(float x); long double cbrtl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cbrt() functions shall compute the real cube root of x. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The cbrt() functions shall return x**1/3 . If x is 1Inf, the cbrt() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The cbrt() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE For some applications, a true cube root function, which returns negative results for negative arguments, is more appropriate than pow(x, 1.0/3.0), which returns a NaN for x less than 0. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 88 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 28) [tog-c99-xsh 4] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 165 Line: 5267 Section: casin Problem: Change required for alignment with C99 (ref C99 section 7.3.5.2). Action: Add the following entry after line 5267: NAME casin - complex arc sine functions SYNOPSIS #include double complex casin(double complex z); float complex casinf(float complex z); long double complex casinl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The casin family of functions shall compute the complex arc sine of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The casin family of functions shall return the complex arc sine value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [-pi/2, +pi/2] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO csin(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 89 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 43) [tog-c99-xsh 19] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 165 Line: 5267 Section: carg Problem: Change required for alignment with C99 (ref C99 section 7.3.9.1). Action: Add the following entry after line 5267: NAME carg - complex argument functions SYNOPSIS #include double carg(double complex z); float cargf(float complex z); long double cargl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The carg family of functions shall compute the argument (also called phase angle) of z, with a branch cut along the negative real axis. RETURN VALUE The carg family of functions shall return the value of the argument in the interval [-pi, +pi]. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cimag(), conj(), cproj(), creal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 90 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 35) [tog-c99-xsh 11] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 167 Line: 5267 Section: catanh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.3). Action: Add the following entry after line 5267: NAME catanh - complex arc hyperbolic tangent functions SYNOPSIS #include double complex catanh(double complex z); float complex catanhf(float complex z); long double complex catanhl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The catanh family of functions shall compute the complex arc hyperbolic tangent of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The catanh family of functions shall return the complex arc hyperbolic tangent value, in the range of a strip mathematically unbounded along the real axis and in the interval [-ipi/2, +ipi/2] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ctanh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 91 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 29) [tog-c99-xsh 5] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as below but list the functions _____________________________________________________________________________ Page: 167 Line: 5267 Section: catan Problem: Change required for alignment with C99 (ref C99 section 7.3.5.3). Action: Add the following entry after line 5267: NAME catan - complex arc tangent functions SYNOPSIS #include double complex catan(double complex z); float complex catanf(float complex z); long double complex catanl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The catan family of functions shall compute the complex arc tangent of z, with branch cuts outside the interval [-i, +i] along the imaginary axis. RETURN VALUE The catan family of functions shall return the complex arc tangent value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [-pi/2, +pi/2] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ctan(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ Objection Enhancement Request Number 92 donnte@microsoft.com Bug in XSHd3 (rdvk# 467) [DT-XSH-35] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: all the places where catalog_closes happen are explictly listed in those functions (e.g. *exit(), exec*() etc). and do not to be covered here _____________________________________________________________________________ Page: 169 Line: 5363 Section: catopen Problem: General problem. There's a lot of weasel wording about closes of files. In this case a perverse reading of this could imply that a message catalog remains open after an exit(). (Yeah, it's a stretch, but it's easy to fix.) Action: Repeatedly we have the same problem: files stay open until exec() or exit or abnormal termination or.... 1) Change "... until that..." to "until closed by catclose() or an implicit close." 2) Add to XBD the definition: implicit close A closure of a file descriptor or other openable object caused by: termination of the process by returning from main(), exit() or _exit(); a signal, or other abnormal termination; when the process executes one of the exec() family of functions or posix_spawn(), and the object is not explicitly carried forward into the new image. Unless specifically stated, it is unspecified whether closure by the explicit close function for the object type or implicit close via exit() (but not _exit) has the same effects as an implicit close by any other means. Not all object types which are subject to an implicit close can be brought forward into the new process image created by the exec functions or posix_spawn(). Add at 5372: Message catalog descriptors are not preserved whenever an implicit close might occur. Delete 5399-5400. _____________________________________________________________________________ comment Enhancement Request Number 93 drepper@redhat.com Bug in XSHd3 (rdvk# 6) {ud-14} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: implementations could define other things as extensions. The standard does not specify what happens in the case given, and should remain so. (its unspecified) _____________________________________________________________________________ Page: 169 Line: 5368 Section: catopen() Problem: The draft currently says: If the value if the oflag is 0, the LANG environment variable is used to locate the catalog without regard to the LC_MESSAGES category. If the oflag argument is NL_CAT_LOCALE, the LC_MESSAGES category is used to locate the message catalog [...]. What happens if oflag is neither 0 nor NL_CAT_LOCALE? Action: Either make the behaviour implementation defined (there might be implementation which allow other mechanisms although I don't know about any) or make it an error and add [EINVAL] The oflag parameter is neither 0 nor NL_CAT_LOCALE. to t