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 the error section under mandatory errors. _____________________________________________________________________________ objection Enhancement Request Number 94 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 30) [tog-c99-xsh 6] 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: 171 Line: 5455 Section: ccos Problem: Change required for alignment with C99 (ref C99 section 7.3.5.4). Action: Add the following entry after line 5455: NAME ccos - complex cosine functions SYNOPSIS #include double complex ccos(double complex z); float complex ccosf(float complex z); long double complex ccosl(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 ccos family of functions shall compute the complex cosine of z. RETURN VALUE The ccos family of functions shall return the complex cosine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cacos(), 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 95 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 36) [tog-c99-xsh 12] 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: 171 Line: 5455 Section: ccosh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.4). Action: Add the following entry after line 5455: NAME ccosh - complex hyperbolic cosine functions SYNOPSIS #include double complex ccosh(double complex z); float complex ccoshf(float complex z); long double complex ccoshl(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 ccosh family of functions shall compute the complex hyperbolic cosine of z. RETURN VALUE The ccosh family of functions shall return the complex hyperbolic cosine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cacosh(), 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 96 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 171) [tog-c99-xsh 145] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 172 Line: 5460 Section: ceil Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Add after line 5460: float ceilf(float x); long double ceill(long double x); [Ed note: Add to CH The ceilf() and ceill() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 97 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 172) [tog-c99-xsh 146] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The ceil( ) function ..." To "The ceil(), ceilf() and ceill() functions ..." Same change on lines 5475 and 5477. _____________________________________________________________________________ Page: 172 Line: 5465 Section: ceil Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Change "The ceil( ) function ..." To "The ceil family of functions ..." Same change on lines 5475 and 5477. _____________________________________________________________________________ objection Enhancement Request Number 98 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 173) [tog-c99-xsh 147] 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, ceil( ) ..." To "Upon successful completion, the ceil(), ceilf() and ceill() functions ..." _____________________________________________________________________________ Page: 172 Line: 5469 Section: ceil Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Change "Upon successful completion, ceil( ) ..." To "Upon successful completion, the ceil family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 99 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 39) [tog-c99-xsh 15] 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: 173 Line: 5506 Section: cexp Problem: Change required for alignment with C99 (ref C99 section 7.3.7.1). Action: Add the following entry after line 5506: NAME cexp - complex exponential functions SYNOPSIS #include double complex cexp(double complex z); float complex cexpf(float complex z); long double complex cexpl(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 cexp family of functions shall compute the complex base-e exponential of z. RETURN VALUE The cexp family of functions shall return the complex base-e exponential value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO clog(), 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 100 donnte@microsoft.com Bug in XSHd3 (rdvk# 468) [DT-XSH-36] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: As it stands, this text does not fit in File Access permissions. While the reviewers agreed that it was probably out of place, no one could agree on where it should go to. Please resubmit aardvark with a better target. _____________________________________________________________________________ Page: 184 Line: 5785 Section: chmod Problem: See ERN #79. This text does not belong here any more than a description of the meaning of S_IRUSR does. The addition of a definition (see 5793) is a good thing. Move this text to File Access Permissions (4.1) as it's really about that. Action: 1) Close on new definition. 2) Move this to File Access Permissions (Section 4.1). _____________________________________________________________________________ Objection Enhancement Request Number 101 donnte@microsoft.com Bug in XSHd3 (rdvk# 469) [DT-XSH-37] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: replace "may" with "could possibly" in the existing text. Add "This behavior will not occur in an conforming environment." to end _____________________________________________________________________________ Page: 186 Line: 5863 Section: chmod Problem: "file descriptors may become invalid" (for NFS). 1) This is a normative requirement in Application Usage. 2) In a normative location, I would find this wording VERY objectionable. Action: Delete it. If you wish replace with: When using filesystems not specified by this standard (and thus operating outside the scope of this standard) it can occur that access to an open file is denied if the result of chmod() would prevent the file from being opened (for example on stateless filesystems). This behavior is prohibited in an conforming environment. _____________________________________________________________________________ objection Enhancement Request Number 102 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 44) [tog-c99-xsh 20] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept below but list the functions _____________________________________________________________________________ Page: 191 Line: 6052 Section: cimag Problem: Change required for alignment with C99 (ref C99 section 7.3.9.2). Action: Add the following entry after line 6052: NAME cimag - complex imaginary functions SYNOPSIS #include double cimag(double complex z); float cimagf(float complex z); long double cimagl(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 cimag family of functions shall compute the imaginary part of z. RETURN VALUE The cimag family of functions shall return the imaginary part value (as a real). ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE For a variable z of complex type, z == creal(z) + cimag(z)*I. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), 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 103 donnte@microsoft.com Bug in XSHd3 (rdvk# 470) [DT-XSH-38] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: we do not shade informative sections _____________________________________________________________________________ Page: 193 Line: 6106 Section: clock Problem: XSI not shaded. Action: Shade "The resolution..." _____________________________________________________________________________ editorial Enhancement Request Number 104 prindle@voicenet.com Bug in XSHd3 (rdvk# 634) [prindle.xsh-4] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_105 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 195 Line: 6134 Section: clock_getcpuclockid() Problem: Missing return type. Action: Add "int" before the function name. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 105 drepper@redhat.com Bug in XSHd3 (rdvk# 7) {ud-15} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 195 Line: 6134 Section: clock_getcpuclockid() Problem: The prototype for clock_getcpuclockid() is incomplete. Action: I don't have access to the 1003.1d-1999 standard so I have to guess that the return type is int. Therefore change the line to int clock_getcpuclockid(pid_t pid, clockid_t *clock_id); _____________________________________________________________________________ Objection Enhancement Request Number 106 donnte@microsoft.com Bug in XSHd3 (rdvk# 471) [DT-XSH-39] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the paragraphs are not the same, the actions differ. _____________________________________________________________________________ Page: 196 Line: 6193 Section: clock_getres Problem: EMB Text duplicated a line 6213. Action: Delete copy at 6213. (2 paragraphs worth!). _____________________________________________________________________________ editorial Enhancement Request Number 107 drepper@redhat.com Bug in XSHd3 (rdvk# 8) {ud-16} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6226 Section: clock_getres() Problem: (Also line 6235.) The text says: [...] when invoking one of the clock() or timer*() functions. This is misleading. clock() would refer to the function clock() and not the functions named clock_*() which is meant here. Action: Change all occurrences of clock() or timer*() to clock_*() or timer_*() Please note the additional underscore character in the clock_*() and timer_*() name and the asterisk in clock_*(). _____________________________________________________________________________ editorial Enhancement Request Number 108 prindle@voicenet.com Bug in XSHd3 (rdvk# 635) [prindle.xsh-5] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_107 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 197 Line: 6226,6235 Section: clock_getres() Problem: There are several clock_*() functions, distinct from the clock() function. Action: Change "clock()" on these two lines to "clock_*()". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 109 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 40) [tog-c99-xsh 16] 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: 201 Line: 6394 Section: clog Problem: Change required for alignment with C99 (ref C99 section 7.3.7.2). Action: Add the following entry after line 6394: NAME clog - complex natural logarithm functions SYNOPSIS #include double complex clog(double complex z); float complex clogf(float complex z); long double complex clogl(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 clog family of functions shall compute the complex natural (base-e) logarithm of z, with a branch cut along the negative real axis. RETURN VALUE The clog family of functions shall return the complex natural logarithm value, in the range of a strip mathematically unbounded 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 cexp(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ comment Enhancement Request Number 110 drepper@redhat.com Bug in XSHd3 (rdvk# 9) {ud-17} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 203 Line: 6463 Section: close() Problem: The first example for close (Reassigning a File Descriptor) assumes that the stdin file descriptor is not closed. But this is not explicitly mentioned. Furthermore, what the example does could be easier achieved using dup2(). I think this should also be mentioned since otherwise readers might think that this example is really as good as it gets. (Yeah, I know, I'm pedantic.) Action: Add another sentence at line 6463. This example assumes that the file descriptor 0 (which is the descriptor for standard input) is not closed. Following the example add: Incidently, this is exactly what could be achieved using dup2 (pfd, 1); close (pfd); _____________________________________________________________________________ Editorial Enhancement Request Number 111 donnte@microsoft.com Bug in XSHd3 (rdvk# 472) [DT-XSH-40] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 204 Line: 6495 Section: close Problem: Bad case. Action: "this" -> "This". _____________________________________________________________________________ Comment Enhancement Request Number 112 donnte@microsoft.com Bug in XSHd3 (rdvk# 473) [DT-XSH-41] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "random" in the existing text to "arbitrary" _____________________________________________________________________________ Page: 207 Line: 6615 Section: closelog Problem: "random processes" ... ones that execute random instructions? Ones that execute unpredictably? Ones that generate random numbers? Ones that are irrelevant? Action: -> by any process which calls the logging functions". _____________________________________________________________________________ Editorial Enhancement Request Number 113 donnte@microsoft.com Bug in XSHd3 (rdvk# 475) [DT-XSH-43] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Italicize "openlog" and change to "openlog()". _____________________________________________________________________________ Page: 208 Line: 6652 Section: closelog Problem: wrong font, notation. Action: Italicize "openlog" and change to "openlog()". Also, should this sentence and the similar one at 6646 be combined? _____________________________________________________________________________ Comment Enhancement Request Number 114 donnte@microsoft.com Bug in XSHd3 (rdvk# 474) [DT-XSH-42] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "random" in the existing text to "arbitrary" _____________________________________________________________________________ Page: 209 Line: 6674 Section: closelog Problem: "random" again. Action: Same as above. _____________________________________________________________________________ objection Enhancement Request Number 115 ajosey@opengroup.org Bug in XSHd3 (rdvk# 411) {c99-confstr-1} Sun, 30 Apr 2000 08:38:38 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 211 Line: 6712 Section: confstr Problem: As part of the introduction of the new c99 utility, we need to mark obsolete (LEGACY) the macros associated with the data models used by c89 , and introduce new macros for the data models used by c99. (see also the changes to create the XCU c99 man page c99-c99-1) Action: Copy lines 6712-6727 , renaming occurrences of "XBS5" to "POSIX_V6" Retain the existing lines as XSI, and mark them LEGACY. Ensure the SEE ALSO on line 6784 points to c99 in XCU. Update the Change History The macros associated with the c89 programming models are marked LEGACY and new equivalent macros associated with c99 are introduced. _____________________________________________________________________________ comment Enhancement Request Number 116 drepper@redhat.com Bug in XSHd3 (rdvk# 10) {ud-18} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the command utility is used to obviate a security hole. It is described in XCU _____________________________________________________________________________ Page: 212 Line: 6772 Section: confstr() Problem: The draft says: Application developers can normally determine any configuration variable by means of reading from the stream opened by a call to: popen("command -p getconf variable", "r"); I don't understand this. What is `command4? Why isn't getconf used directly? Also, `variable' must be replaced by something and bot be used verbatim. Action: Replace line 6772 with popen("getconf variable", "r"); where `variable' is printed cursive. _____________________________________________________________________________ Comment Enhancement Request Number 117 donnte@microsoft.com Bug in XSHd3 (rdvk# 476) [DT-XSH-44] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 212 Line: 6778 Section: confstr Problem: "lightweight processes" is not defined. Action: Change to "threads" (I think). _____________________________________________________________________________ objection Enhancement Request Number 118 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 45) [tog-c99-xsh 21] 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: 213 Line: 6801 Section: conj Problem: Change required for alignment with C99 (ref C99 section 7.3.9.3). Action: Add the following entry after line 6801: NAME conj - complex conjugate functions SYNOPSIS #include double complex conj(double complex z); float complex conjf(float complex z); long double complex conjl(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 conj family of functions compute the complex conjugate of z, by reversing the sign of its imaginary part. RETURN VALUE The conj family of functions return the complex conjugate value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), 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 119 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 192) [tog-c99-xsh 166] 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: 216 Line: 6910 Section: copysign Problem: Change required for alignment with C99 (ref C99 section 7.12.11.1). Action: Add the following entry after line 6910: NAME copysign - number manipulation function SYNOPSIS #include double copysign(double x, double y); float copysignf(float x, float y); long double copysignl(long double x, long double y); 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 copysign() functions shall produce a value with the magnitude of x and the sign of y. They produce a NaN (with the sign of y) if x is a NaN. On implementations that represent a signed zero but do not treat negative zero consistently in arithmetic operations, the copysign functions regard the sign of zero as positive. 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 copysign() functions shall return a value with the magnitude of x and the sign of y. If x is 1Inf, the copysign() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The copysign() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE copysign and signbit need not be consistent with each other if the arithmetic is not consistent in its treatment of zeros. For example, the IBM S/370 has instructions to flip the sign bit making it possible to create a negative zero, but 10.0 W 11.0 is always +0.0. In this case, copysign will treat 0.0 as positive, while signbit will treat it as negative. 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 120 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 86) [tog-c99-xsh 62] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 217 Line: 6915 Section: cos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Add after line 6915: float cosf(float x); long double cosl(long double x); [Ed note: Add to CH The cosf() and cosl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 121 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 87) [tog-c99-xsh 63] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The cos( ) function ..." To "The cos(), cosf() and cosl() functions ..." Same change on line 6930. _____________________________________________________________________________ Page: 217 Line: 6920 Section: cos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Change "The cos( ) function ..." To "The cos family of functions ..." Same change on line 6930. _____________________________________________________________________________ objection Enhancement Request Number 122 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 88) [tog-c99-xsh 64] 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, cos( ) ..." To "Upon successful completion, the cos(), cosf() and cosl() functions ..." _____________________________________________________________________________ Page: 217 Line: 6924 Section: cos Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Change "Upon successful completion, cos( ) ..." To "Upon successful completion, the cos family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 123 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 101) [tog-c99-xsh 77] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 219 Line: 6966 Section: cosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Add after line 6966: float coshf(float x); long double coshl(long double x); [Ed note: Add to CH The coshf() and coshl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 124 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 102) [tog-c99-xsh 78] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The cosh( ) function ..." To "The cosh(), coshf(), and coshl() functions ..." Same change on lines 6979 and 6981. _____________________________________________________________________________ Page: 219 Line: 6971 Section: cosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Change "The cosh( ) function ..." To "The cosh family of functions ..." Same change on lines 6979 and 6981. _____________________________________________________________________________ objection Enhancement Request Number 125 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 103) [tog-c99-xsh 79] 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, cosh( ) ..." To "Upon successful completion, the cosh(), coshf(), and coshl() functions ..." _____________________________________________________________________________ Page: 219 Line: 6975 Section: cosh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Change "Upon successful completion, cosh( ) ..." To "Upon successful completion, the cosh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 126 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 47) [tog-c99-xsh 23] 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: 220 Line: 7005 Section: creal Problem: Change required for alignment with C99 (ref C99 section 7.3.9.5). Action: Add the following entry after line 7005: NAME creal - complex real functions SYNOPSIS #include double creal(double complex z); float crealf(float complex z); long double creall(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 creal family of functions shall compute the real part of z. RETURN VALUE The creal family of functions shall return the real part value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE For a variable z of complex type, z == creal(z) + cimag(z)*I. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), conj(), cproj(), 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 127 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 46) [tog-c99-xsh 22] 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: 220 Line: 7005 Section: cproj Problem: Change required for alignment with C99 (ref C99 section 7.3.9.4). Action: Add the following entry after line 7005: NAME cproj - complex projection functions SYNOPSIS #include double complex cproj(double complex z); float complex cprojf(float complex z); long double complex cprojl(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 cproj family of functions shall compute a projection of z onto the Riemann sphere: z projects to z except that all complex infinities (even those with one infinite part and one NaN part) project to positive infinity on the real axis. If z has an infinite part, then cproj(z) is equivalent to INFINITY + I * copysign(0.0, cimag(z)) RETURN VALUE The cproj family of functions shall return the value of the projection onto the Riemann sphere. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE Two topologies are commonly used in complex mathematics: the complex plane with its continuum of infinities, and the Riemann sphere with its single infinity. The complex plane is better suited for transcendental functions, the Riemann sphere for algebraic functions. The complex types with their multiplicity of infinities provide a useful (though imperfect) model for the complex plane. The cproj function helps model the Riemann sphere by mapping all infinities to one, and should be used just before any operation, especially comparisons, that might give spurious results for any of the other infinities. Note that a complex value with one infinite part and one NaN part is regarded as an infinity, not a NaN, because if one part is infinite, the complex value is infinite independent of the value of the other part. For the same reason, cabs returns an infinity if its argument has an infinite part and a NaN part. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), conj(), 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 128 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 41) [tog-c99-xsh 17] 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: 220 Line: 7005 Section: cpow Problem: Change required for alignment with C99 (ref C99 section 7.3.8.2). Action: Add the following entry after line 7005: NAME cpow - complex power functions SYNOPSIS #include double complex cpow(double complex x, double complex y); float complex cpowf(float complex x, float complex y); long double complex cpowl(long double complex x, long double complex y); 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 cpow family of functions shall compute the complex power function x**y, with a branch cut for the first parameter along the negative real axis. RETURN VALUE The cpow family of functions shall return the complex power function value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cabs(), csqrt(), 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 129 donnte@microsoft.com Bug in XSHd3 (rdvk# 477) [DT-XSH-45] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: just because there is a replacement doesn't mean that it becomes legacy (breaks the contract with the application developer) _____________________________________________________________________________ Page: 221 Line: 7007 Section: creat Problem: Another good candidate for legacy. I know it was in the original .1, but it still should be legacy at this point. (It's right on the edge of being able to delete it; I rarely see calls to it.) Action: Mark legacy. _____________________________________________________________________________ objection Enhancement Request Number 130 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 37) [tog-c99-xsh 13] 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: 224 Line: 7140 Section: csinh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.5). Action: Add the following entry after line 7140: NAME csinh - complex hyperbolic sine functions SYNOPSIS #include double complex csinh(double complex z); float complex csinhf(float complex z); long double complex csinhl(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 csinh family of functions shall compute the complex hyperbolic sine of z. RETURN VALUE The csinh family of functions shall return the complex hyperbolic sine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO casinh(), 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 131 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 42) [tog-c99-xsh 18] 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: 224 Line: 7140 Section: csqrt Problem: Change required for alignment with C99 (ref C99 section 7.3.8.3). Action: Add the following entry after line 7140: NAME csqrt - complex square root functions SYNOPSIS #include double complex csqrt(double complex z); float complex csqrtf(float complex z); long double complex csqrtl(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 csqrt family of functions shall compute the complex square root of z, with a branch cut along the negative real axis. RETURN VALUE The csqrt family of functions shall return the complex square root value, in the range of the right half-plane (including the imaginary axis). ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cabs(), cpow(), 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 132 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 38) [tog-c99-xsh 14] 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 [LTF] _____________________________________________________________________________ Page: 224 Line: 7140 Section: ctanh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.6). Action: Add the following entry after line 7140: NAME ctanh - complex hyperbolic tangent functions SYNOPSIS #include double complex ctanh(double complex z); float complex ctanhf(float complex z); long double complex ctanhl(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 ctanh family of functions shall compute the complex hyperbolic tangent of z. RETURN VALUE The ctanh family of functions shall return the complex hyperbolic tangent value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO catanh(), 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 133 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 31) [tog-c99-xsh 7] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 224 Line: 7140 Section: csin Problem: Change required for alignment with C99 (ref C99 section 7.3.5.5). Action: Add the following entry after line 7140: NAME csin - complex sine functions SYNOPSIS #include double complex csin(double complex z); float complex csinf(float complex z); long double complex csinl(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 csin family of functions shall compute the complex sine of z. RETURN VALUE The csin family of functions shall return the complex sine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO casin(), 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 134 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 32) [tog-c99-xsh 8] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 224 Line: 7140 Section: ctan Problem: Change required for alignment with C99 (ref C99 section 7.3.5.6). Action: Add the following entry after line 7140: NAME ctan - complex tangent functions SYNOPSIS #include double complex ctan(double complex z); float complex ctanf(float complex z); long double complex ctanl(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 ctan family of functions shall compute the complex tangent of z. RETURN VALUE The ctan family of functions shall return the complex tangent value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO catan(), 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 135 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 34) [tog-c99-xsh 10] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 224 Line: 7140 Section: casinh Problem: Change required for alignment with C99 (ref C99 section 7.3.6.2). Action: Add the following entry after line 7140: NAME casinh - complex arc hyperbolic sine functions SYNOPSIS #include double complex casinh(double complex z); float complex casinhf(float complex z); long double complex casinhl(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 casinh family of functions shall compute the complex arc hyperbolic sine of z, with branch cuts outside the interval [-i, +i] along the imaginary axis. RETURN VALUE The casinh family offunctions shall return the complex arc hyperbolic sine 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 csinh(), 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 136 donnte@microsoft.com Bug in XSHd3 (rdvk# 479) [DT-XSH-47] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: we cannot see the duplicated text (line numbers wrong?) _____________________________________________________________________________ Page: 225 Line: 7148 Section: ctermid Problem: Text is duplicated at 7149. Action: Delete here. _____________________________________________________________________________ Comment Enhancement Request Number 137 donnte@microsoft.com Bug in XSHd3 (rdvk# 478) [DT-XSH-46] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove the "+1" , also the same change on 7166, 7169 _____________________________________________________________________________ Page: 225 Line: 7180 Section: ctermid Problem: Either I'm missing something or the "+1" at line 7169 isn't needed. Action: "+1" -> "". _____________________________________________________________________________ Objection Enhancement Request Number 138 donnte@microsoft.com Bug in XSHd3 (rdvk# 480) [DT-XSH-48] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change at line 7345: "These database functions shall support an internal block size large enough to support key/content pairs of at least 1 023 bytes." _____________________________________________________________________________ Page: 231 Line: 7326 Section: dbm_clearerr Problem: The term "block" in this context is undefined. How big is it, can it be controlled, etc. Also is "block" and the constant "1023" on line 7345 related? Action: Define... ask a dbm expert what's meant. _____________________________________________________________________________ Objection Enhancement Request Number 139 donnte@microsoft.com Bug in XSHd3 (rdvk# 481) [DT-XSH-49] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 235 Line: 7495 Section: dirname Problem: 1) munged text near //foo 2) It's a one-character string, not a character constant, so it should be "/". Action: "the dirname" -> "dirname("//foo") may return either "//" or "/" (but nothing else)". _____________________________________________________________________________ Objection Enhancement Request Number 140 donnte@microsoft.com Bug in XSHd3 (rdvk# 482) [DT-XSH-50] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: It is historic practice. The submitter did not expect this to be accepted. _____________________________________________________________________________ Page: 239 Line: 7601 Section: dlerror Problem: For the record (I know you won't accept this one)... this is the most horrifically awful interface because it's NOT possible to program (portably) to deal with errors because they're unspecified strings. The text for regcmp (page 1109, line 33701) makes my case for me very nicely. Action: Preferably replace it with something that returns error numbers that then can be converted to strings for printing. (This could be defined as a wrapper function on something portably useful.) Last time you argued "out of scope" on this change. If it's an XSI interface, then ISO/IEEE can't say whether it's out of scope or not (and thus changes can be made by TOG); if XOTGSI (or whatever it is) doesn't choose to fix it, I can't make them, but that doesn't change the fact that the interface is awful (to the point of embarrassing). If it's not an XSI interface, then it may be out of scope to change it (and I recommend changing the PAR so it can be fixed). _____________________________________________________________________________ Objection Enhancement Request Number 141 donnte@microsoft.com Bug in XSHd3 (rdvk# 483) [DT-XSH-51] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: relocation and relocatable file are both defined in XBD, as in AUSTIN/34r1 _____________________________________________________________________________ Page: 241 Line: 7676 Section: dlopen Problem: See ERN #94 The concept of "relocation" is undefined (as noted last time). This was referred to the Base WG, but I don't see any result. Action: Report result of WG deliberations (preferably with a definition or a reference to one.) _____________________________________________________________________________ Editorial Enhancement Request Number 142 donnte@microsoft.com Bug in XSHd3 (rdvk# 484) [DT-XSH-52] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "shall be" to "are" or similar (editor, do the right thing ...) _____________________________________________________________________________ Page: 242 Line: 7694 Section: dlopen Problem: Tense clash in this sentence... overaggressive shallification. Action: "shall be" -> "have been made" or "will". _____________________________________________________________________________ Objection Enhancement Request Number 143 donnte@microsoft.com Bug in XSHd3 (rdvk# 485) [DT-XSH-53] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: these functions are useful, and can be/have been implemented on secure systems _____________________________________________________________________________ Page: 256 Line: 8153 Section: endgrent Problem: See ERN# 98 and 99 (Note... the issues in 98 did not fully duplicate those in 99. I claim the ones in 98 are more serious.) Another good case for legacy. Also, these interfaces cannot be (usefully) implemented on some secure systems, because enumerating users (or groups) is considered a security violation. Action: Make legacy (or delete). Applies to all the "enumerate user/group database" functions. Add to rationale the text from POSIX.1-1990 for B.9.1, particularly the paragraph at 293/4541. _____________________________________________________________________________ editorial Enhancement Request Number 144 tomp@zk3.dec.com Bug in XSHd3 (rdvk# 673) {compaq-tap-003} Mon, 1 May 2000 08:14:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 258 Line: 8192 Section: endhostent Problem: Typo. The first instance of "hostent" should be "ptr" to correctly refer to the ptr argument, rather than its type. Action: Change the first instance of "hostent" on line 8192 to "ptr", changing the boldface type to italics. _____________________________________________________________________________ Objection Enhancement Request Number 145 donnte@microsoft.com Bug in XSHd3 (rdvk# 486) [DT-XSH-54] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "opening a connection to the database as necessary" to "opening and closing a connection to the database as necessary" Do the same on 8244, 8297 and 8414 _____________________________________________________________________________ Page: 258 Line: 8196 Section: endhostent Problem: "possibly opening a connection to the database"... what happens to it afterwards? I see two alternatives: always close it or allow it to be closed (depends on what you want to do about tied up fds.) Action: My preference: add "and closing it afterwards unless stayopen was set (see below)". Same change to 8244, 8297, 8416. _____________________________________________________________________________ objection Enhancement Request Number 146 prindle@voicenet.com Bug in XSHd3 (rdvk# 636) [prindle.xsh-6] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 258 Line: 8200 Section: endhostent() Problem: These functions are not thread safe in two different ways (there has been recent email discussion regarding flavors of thread safety). gethostent() is not safe because it returns a pointer to a potentially static structure. They all are not thread safe because of the positional state retained among them - i.e. separate threads expecting to search independently through or rewind the database will interfere with each other. You've made a decision in the other get*ent()/set*ent()/end*ent() type functions to consider the entire set non-thread-safe. Action: Add (as in endgrent()) the following paragraph: These functions need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 147 prindle@voicenet.com Bug in XSHd3 (rdvk# 637) [prindle.xsh-7] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 260 Line: 8253 Section: endnetent() Problem: These functions are not thread safe in two different ways (there has been recent email discussion regarding flavors of thread safety). getnet*() are not safe because they returns pointers to potentially static structures. They all are not thread safe because of the positional state retained among them - i.e. separate threads expecting to search independently through or rewind the database will interfere with each other. You've made a decision in the other get*ent()/set*ent()/end*ent() type functions to consider the entire set non-thread-safe. Action: Add (as in endgrent()) the following paragraph: These functions need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 148 tomp@zk3.dec.com Bug in XSHd3 (rdvk# 674) {compaq-tap-004} Mon, 1 May 2000 08:14:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 262 Line: 8294 Section: endprotoent Problem: Typo. The second instance of the word "number" should refer to the "proto" argument to getprotobynumber. Action: Change the second instance of "number" on line 8294 to "proto". _____________________________________________________________________________ objection Enhancement Request Number 149 prindle@voicenet.com Bug in XSHd3 (rdvk# 638) [prindle.xsh-8] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 262 Line: 8305 Section: endprotoent() Problem: These functions are not thread safe in two different ways (there has been recent email discussion regarding flavors of thread safety). getproto*() are not safe because they returns pointers to potentially static structures. They all are not thread safe because of the positional state retained among them - i.e. separate threads expecting to search independently through or rewind the database will interfere with each other. You've made a decision in the other get*ent()/set*ent()/end*ent() type functions to consider the entire set non-thread-safe. Action: Add (as in endgrent()) the following paragraph: These functions need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 150 donnte@microsoft.com Bug in XSHd3 (rdvk# 488) [DT-XSH-56] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN 143 _____________________________________________________________________________ Page: 264 Line: 8370 Section: endpwent Problem: A good case to mark it legacy. Action: Mark legacy. _____________________________________________________________________________ objection Enhancement Request Number 151 prindle@voicenet.com Bug in XSHd3 (rdvk# 639) [prindle.xsh-9] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 266 Line: 8422 Section: endservent() Problem: These functions are not thread safe in two different ways (there has been recent email discussion regarding flavors of thread safety). getserv*() are not safe because they returns pointers to potentially static structures. They all are not thread safe because of the positional state retained among them - i.e. separate threads expecting to search independently through or rewind the database will interfere with each other. You've made a decision in the other get*ent()/set*ent()/end*ent() type functions to consider the entire set non-thread-safe. Action: Add (as in endgrent()) the following paragraph: These functions need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 152 donnte@microsoft.com Bug in XSHd3 (rdvk# 487) [DT-XSH-55] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Current text in description of kill() from P647, L20375-20377: An implementation that provides extended security controls may impose further implementation-dependent restrictions on the sending of signals, including the null signal. In particular, the system may deny the existence of some or all of the processes specified by pid. Fix for XSH ERN #152: Add as new paragraph after P269, L8499 (endutxent()): An implementation that provides extended security controls may impose further implementation-defined restrictions on accessing the user accounting database. In particular, the system may deny the existence of some or all of the user accounting database entries associated with users other than the caller. Associated fixes: Add as new paragraph after P264, L8342 (endpwent()): An implementation that provides extended security controls may impose further implementation-defined restrictions on accessing the user database. In particular, the system may deny the existence of some or all of the user database entries associated with users other than the caller. Add as new paragraph after P256, L8134 (endgrent()): An implementation that provides extended security controls may impose further implementation-defined restrictions on accessing the group database. In particular, the system may deny the existence of some or all of the group database entries associated with groups other than those groups associated with the caller and may omit users other than the caller from the list of members of groups in database entries that are returned. _____________________________________________________________________________ Page: 268 Line: 8458 Section: endpwent Problem: A security hole. On some systems, even knowing who else is on the system is considered a security breach. Action: Add: "In the absence of appropriate privilege, these interfaces need not return anything (may behave as if the database is empty), may return synthetic information, or a subset of the actual database content." _____________________________________________________________________________ objection Enhancement Request Number 153 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 159) [tog-c99-xsh 134] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8555 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Add after line 8555: float erff(float x); long double erfl(long double x); [Ed note: Add to CH The erfcf(), erfcl(), erff() and erfl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 154 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 160) [tog-c99-xsh 135] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 273 Line: 8557 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.2). Action: Add after line 8557: float erfcf(float x); long double erfcl(long double x); _____________________________________________________________________________ objection Enhancement Request Number 155 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 161) [tog-c99-xsh 136] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The erf( ) function ..." To "The erf(), erff(), and erfl() functions ..." _____________________________________________________________________________ Page: 273 Line: 8559 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Change "The erf( ) function ..." To "The erf family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 156 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 162) [tog-c99-xsh 137] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "The erfc(), erfcf(), and erfcl() functions ..." _____________________________________________________________________________ Page: 273 Line: 8561 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.2). Action: Change "The erfc( ) function ..." To "The erfc family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 157 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 163) [tog-c99-xsh 138] 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, erf() and erfc() ..." To "Upon successful completion, the erf(), erff(), erfl(), erfc() erfcf() and erfcl() functions ..." _____________________________________________________________________________ Page: 273 Line: 8565 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Change "Upon successful completion, erf() and erfc() ..." To "Upon successful completion, the erf() and erfc() functions ..." _____________________________________________________________________________ objection Enhancement Request Number 158 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 164) [tog-c99-xsh 139] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add after line 8570: "The erfc(), erfcf() and erfcl() functions shall fail if: [ERANGE] The value of x is too large. _____________________________________________________________________________ Page: 273 Line: 8570 Section: erf Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Add after line 8570: The erfc() functions shall fail if: [ERANGE] The value of x is too large. _____________________________________________________________________________ Editorial Enhancement Request Number 159 donnte@microsoft.com Bug in XSHd3 (rdvk# 489) [DT-XSH-57] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 8691 Section: exec Problem: shallification Action: "use" -> "shall use". _____________________________________________________________________________ Objection Enhancement Request Number 160 donnte@microsoft.com Bug in XSHd3 (rdvk# 490) [DT-XSH-58] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: Believed to be against line 8691. R: The current wording is correct. EINVAL is defined to mean something different on p280. _____________________________________________________________________________ Page: 277 Line: 8693 Section: exec Problem: The alternative of EINVAL should be mentioned here. Action: "executable object," -> "executable object, and the system does not recognize it as something that cannot be executed (and thus returns EINVAL)," _____________________________________________________________________________ Editorial Enhancement Request Number 161 donnte@microsoft.com Bug in XSHd3 (rdvk# 491) [DT-XSH-59] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete lines 8920-8923 _____________________________________________________________________________ Page: 283 Line: 8920 Section: exec Problem: This paragraph clearly intends to follow some discussion of locks, but it doesn't. Check original editorial instructions. It appears that it's related to the change at 8714; it may be that it was rationale for the change, and needs slight editing to fit into the current rationale. Action: Edit so it fits. The one line paragraph at 8924 may or may not belong in a better place. _____________________________________________________________________________ objection Enhancement Request Number 162 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 287) [tog-c99-xsh 261] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 288 Line: 9096-9097 Section: exit Problem: Change required for alignment with C99 (ref C99 section 7.20.4.3). Action: Change "The exit() function shall first call all functions registered by atexit (), in the reverse order of their registration. Each function is called as many times as it was registered." To "The exit() function shall first call all functions registered by atexit (), in the reverse order of their registration, except that a function is called after any previously registered functions that had already been called at the time it was registered. Each function is called as many times as it was registered. If, during the call to any such function, a call to the longjmp function is made that would terminate the call to the registered function, the behavior is undefined." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Comment Enhancement Request Number 163 donnte@microsoft.com Bug in XSHd3 (rdvk# 492) [DT-XSH-60] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete "this volume" _____________________________________________________________________________ Page: 290 Line: 9172 Section: exit Problem: This discussion has become garbled... it's about the earliest POSIXs (1988 even more than 1990) and should reference the historical documents. (Or consider deleting). Action: Change to refer to historical drafts, not this revision. _____________________________________________________________________________ objection Enhancement Request Number 164 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 288) [tog-c99-xsh 262] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the markup draft for _exit() _____________________________________________________________________________ Page: 292 Line: 9283 Section: _Exit Problem: Change required for alignment with C99 (ref C99 section 7.20.4.4). [Ed. This page should perhaps state that _Exit() is equivalent to _exit(), and simply refer to the exit() page for the DESCRIPTION and RETURN VALUE sections. However, because of the rationale for this function on C99, I have left it as a separate page for the moment, with the text taken more or less directly from C99.] Action: Add the following entry: Name _Exit - terminate process execution without tidying up SYNOPSIS void _Exit(int status); 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 The _Exit() function shall cause normal program termination to occur and control to be returned to the host environment. No functions registered by the atexit function or signal handlers registered by the signal function shall be called. The status returned to the host environment is determined in the same way as for the exit() function. Whether open streams with unwritten buffered data are flushed, open streams are closed, or temporary files are removed is implementation-dependent. RETURN VALUE The _Exit() function shall not return to its caller. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE [Ed. Below are the rationales from C89 and C99 respectively.] (1) The C Standard Committee considered the addition of _exit, but rejected it based on concerns of incompatible with the POSIX specification upon which it is based. For example, one concern expressed is that _exit was specified as a way to get out of a signal handler without triggering another signal, but that is not actually the way _exit behaves in POSIX environments. The C Standard Committee did not wish to give programmers this kind of false hope. (2) A new feature of C9X: the C9X Committee considered it desirable to have an _exit-like function that would result in immediate program termination without triggering signals or atexit-registered functions, but chose the name, _Exit, rather than _exit, because of the potential conflict with existing practice mentioned above. FUTURE DIRECTIONS None. SEE ALSO exit(), 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 165 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 110) [tog-c99-xsh 86] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 293 Line: 9288 Section: exp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Add after line 9288: float expf(float x); long double expl(long double x); [Ed note: Add to CH The expf() and expl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 166 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 111) [tog-c99-xsh 87] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The exp( ) function ..." To "The exp(), expf() and expl() functions ..." Same change on lines 9303 and 9305. _____________________________________________________________________________ Page: 293 Line: 9293 Section: exp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Change "The exp( ) function ..." To "The exp family of functions ..." Same change on lines 9303 and 9305. _____________________________________________________________________________ objection Enhancement Request Number 167 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 112) [tog-c99-xsh 88] 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, exp( ) ..." To "Upon successful completion, the exp(), expf() and expl() functions ..." _____________________________________________________________________________ Page: 293 Line: 9297 Section: exp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Change "Upon successful completion, exp( ) ..." To "Upon successful completion, the exp family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 168 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 113) [tog-c99-xsh 89] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 294 Line: 9329 Section: exp2 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.2). Action: Add the following entry after line 9329: NAME exp2 - exponential base-2 functions SYNOPSIS #include double exp2(double x); float exp2f(float x); long double exp2l(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 exp2 family of functions shall compute the base-2 exponential 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 Upon successful completion, the exp2 family of functions shall return 2**x. If the correct value would cause overflow, the exp2 family of functions shall return HUGE_VAL and set errno to [ERANGE]. If the correct value would cause underflow, the exp2 family of functions shall return 0 and may set errno to [ERANGE]. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The exp2 family of functions shall fail if: [ERANGE] The result overflows. The exp2 family of functions may fail if: [EDOM] The value of x is NaN. [ERANGE] The result underflows No other errors shall occur. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO exp(), isnan(), log(), 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 169 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 114) [tog-c99-xsh 90] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 295 Line: 9335 Section: expm1 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Add after line 9335: float expm1f(float x); long double expm1l(long double x); [Ed note: Add to CH The expm1f() and expm1l() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 170 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 115) [tog-c99-xsh 91] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The expm1( ) function ..." To "The expm1(), expm1f() and expm1l() functions ..." Same change on line 9344. _____________________________________________________________________________ Page: 295 Line: 9337 Section: expm1 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Change "The expm1( ) function ..." To "The expm1 family of functions ..." Same change on line 9344. _____________________________________________________________________________ objection Enhancement Request Number 171 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 116) [tog-c99-xsh 92] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change lines 9339-9342 to: If x is NaN, then the expm1(), expm1f() and expm1l() functions shall return NaN and errno may be set to [EDOM]. If x is positive infinity, the expm1(), expm1f() and expm1l() functions shall return positive infinity. If x is negative infinity, the expm1(), expm1f() and expm1l() functions shall return -1.0. If the value overflows, the expm1(), expm1f() and expm1l() functions shall return HUGE_VAL and may set errno to [ERANGE]. _____________________________________________________________________________ Page: 295 Line: 9339-9342 Section: expm1 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Change lines 9339-9342 to: If x is NaN, then the expm1 family of functions shall return NaN and errno may be set to [EDOM]. If x is positive infinity, the expm1 family of functions shall return positive infinity. If x is negative infinity, the expm1 family of functions shall return -1.0. If the value overflows, the expm1 family of functions shall return HUGE_VAL and may set errno to [ERANGE]. _____________________________________________________________________________ objection Enhancement Request Number 172 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 146) [tog-c99-xsh 122] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 296 Line: 9370 Section: fabs Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Add after line 9370: float fabsf(float x); long double fabsl(long double x); [Ed note: Add to CH The fabsf() and fabsl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 173 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 147) [tog-c99-xsh 123] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The fabs( ) function ..." To "The fabs(), fabsf() and fabsl() functions ..." Same change on line 9383. _____________________________________________________________________________ Page: 296 Line: 9375 Section: fabs Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Change "The fabs( ) function ..." To "The fabs family of functions ..." Same change on line 9383. _____________________________________________________________________________ objection Enhancement Request Number 174 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 148) [tog-c99-xsh 124] 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, fabs( ) ..." To "Upon successful completion, the fabs(), fabsf() and fabsl() functions ..." _____________________________________________________________________________ Page: 296 Line: 9379 Section: fabs Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Change "Upon successful completion, fabs( ) ..." To "Upon successful completion, the fabs family of functions ..." _____________________________________________________________________________ Comment Enhancement Request Number 175 donnte@microsoft.com Bug in XSHd3 (rdvk# 493) [DT-XSH-61] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The reviewers note is in place to alert us for the next draft _____________________________________________________________________________ Page: 298 Line: 9416 Section: fattach Problem: Still an open issue. Get STREAMS expert to determine what really happens and correct. Action: As above. _____________________________________________________________________________ Objection Enhancement Request Number 176 donnte@microsoft.com Bug in XSHd3 (rdvk# 494) [DT-XSH-62] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: this interface is required for security reasons. Leave this function XSI. remove reviewers note _____________________________________________________________________________ Page: 301 Line: 9494 Section: fchdir Problem: Why bother? A portable application shouldn't be opening directories as fds, and you can't get at a fd from a directory stream (that I know of), so where's the target fd supposed to come from? (Or provide an example and some limitations on usage so it isn't abused from whatever the intent was.) Action: Delete function. (Not make XSI or Legacy... delete... it's just a bad idea for a portable program to think it can do this!) _____________________________________________________________________________ Objection Enhancement Request Number 177 donnte@microsoft.com Bug in XSHd3 (rdvk# 495) [DT-XSH-63] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note will be put in place for D4 _____________________________________________________________________________ Page: 304 Line: 9613 Section: fchown Problem: I've learned that streams ignore the call (see fattach()). However, what about AF_UNIX sockets in the filesystem namespace. Action: Ask appropriate experts for clarification. _____________________________________________________________________________ Objection Enhancement Request Number 178 donnte@microsoft.com Bug in XSHd3 (rdvk# 496) [DT-XSH-64] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A revnote for the first part. the other item should be raised in plenary to discuss further _____________________________________________________________________________ Page: 304 Line: 9613 Section: fchown Problem: See old ERN 112. Independent of the type of object, there's an issue with respect to consistency of the document... where is it said which kinds of objects ignore this call (and it's brethren). (Clearly, for the types of object that generate an error, it has to be in ERRORS, but the ones that ignore it (such as fattach()ed streams) are not as clear. Action: At 9542 add: "If fildes refers to a STREAM (which is fattached() into the filesystem namespace) the call returns successfully, doing nothing. If fildes refers to a stream, ." This is a special case of a general action, which I will do if the editors won't: a matrix listing all the various types of object to which a fd might be bound in one dimension and all the calls which take a fd in the other, needs to be generated and filled in with whether the action is taken, ignored, an error, special cased, explicitly unspecified, implementation-defined, or simply interpretation bait (that is, not addressed by the document). The last case needs to be addressed. (Such table should be made part of the document (either informative main line text or rationale) so that it is maintained as new calls or new object types are added). _____________________________________________________________________________ objection Enhancement Request Number 179 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 223) [tog-c99-xsh 197] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 306 Line: 9663 Section: fclose Problem: Change required for alignment with C99 (ref C99 section 7.19.5.1). Action: Change "The stream shall be disassociated from the file." To "Whether or not the call succeeds, the stream shall be disassociated from the file and any buffer set by the setbuf() or setvbuf() function shall be disassociated from the stream" [Ed note: Add to CH The DESCRIPTION is updated to note that the stream and any buffer are disassociated whether or not the call succeed. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 180 donnte@microsoft.com Bug in XSHd3 (rdvk# 497) [DT-XSH-65] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: insert on line 9666-> "shall perform the equivalent of a close()" _____________________________________________________________________________ Page: 306 Line: 9666 Section: fclose Problem: This specifies implementation of fclose (and consequently much of the rest of stdio). POSIX has been VERY careful to allow stdio to be implemented using things other than the real read(), write(), etc. (It's all in terms of "underlying function" and "the equivalent of".) Action: -> "shall perform the equivalent of a close()" and drop the discussion of fds. _____________________________________________________________________________ editorial Enhancement Request Number 181 drepper@redhat.com Bug in XSHd3 (rdvk# 11) {ud-19} Sun, 2 Apr 2000 00:53:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: THIS IS A BUG IN XBD, ACCEPT TO FIX IT IN XBD _____________________________________________________________________________ Page: 311 Line: 10375 Section: Problem: In the description of sockaddr_in6 the types for the first four fields is listed in the second position while for the fifth field the order is reversed. Normally the type is listed first so the first four fields have to be changed. Action: Replace lines 10375 to 10379 with: sa_family_t sin6_family AF_INET6. in_port_t sin6_port Port number. uint32_t sin6_flowinfo IPv6 traffic class and flow information. struct in6_addr sin6_addr IPv6 address. uint32_t sin6_scope_id Set of interfaces for a scope. _____________________________________________________________________________ Objection Enhancement Request Number 182 donnte@microsoft.com Bug in XSHd3 (rdvk# 498) [DT-XSH-66] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove the deprecated sentence. _____________________________________________________________________________ Page: 312 Line: 9908 Section: fcntl Problem: EMB Semaphores ARE included. Action: Replace "Since... " thru the end of the paragraph with: In subsequent revisions of this standard, semaphores were added, which are a better solution to some of the problems historically solved by file locks. The convention of Using file locks as general semaphores is deprecated. _____________________________________________________________________________ Objection Enhancement Request Number 183 donnte@microsoft.com Bug in XSHd3 (rdvk# 499) [DT-XSH-67] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 312 Line: 9940 Section: fcntl Problem: At 9950, "Secondly" is fine, but only if there's a "firstly". The "firstly" is lost because at 9942, the first sentence of the paragraph is not a lead-in for the paragraph (as required by good writing style) but rather an unrelated topic. Action: Add paragraph break after "/usr/group standard." (Yes, this creates a one-line paragraph. Move it if you wish, but to make this discussion make sense, the text "For advisory..." needs to begin the paragraph preceding the one beginning "Secondly...". _____________________________________________________________________________ objection Enhancement Request Number 184 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 201) [tog-c99-xsh 175] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 318 Line: 10114 Section: fdim Problem: Change required for alignment with C99 (ref C99 section 7.12.12.1). Action: Add the following entry after line 10114: NAME fdim - compute positive difference between two floating-point numbers SYNOPSIS #include double fdim(double x, double y); float fdimf(float x, float y); long double fdiml(long double x, long double y); 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 fdim functions shall determine the positive difference between their arguments. If x is greater than y, x - y is returned. If x is less than or equal to y, +0 is returned. 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 fdim() functions shall return the positive difference value. If x or y is NaN, NaN shall be returned and errno may be set to [EDOM]. If the magnitude of the result is too large or too small, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The fdim() functions may fail if: [EDOM] The value of x or y is NaN. [ERANGE] The magnitude of the result is too large or too small. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fmax(), fmin(), 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 185 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 54) [tog-c99-xsh 30] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 321 Line: 10119 Section: fegetround Problem: Change required for alignment with C99 (ref C99 section 7.6.3.1). Action: Add the following entry after line 10119: NAME fegetround - get current rounding direction SYNOPSIS #include int fegetround(void); 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 fegetround() function shall get the current rounding direction. RETURN VALUE The fegetround() function shall return the value of the rounding direction macro representing the current rounding direction or a negative value if there is no such rounding direction macro or the current rounding direction is not determinable. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fesetround(), 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 186 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 56) [tog-c99-xsh 32] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 321 Line: 10119 Section: fegetenv Problem: Change required for alignment with C99 (ref C99 section 7.6.4.1). Action: Add the following entry after line 10119: NAME fegetenv - get current floating-point environment SYNOPSIS #include void fegetenv(fenv_t *envp); 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 fegetenv() function shall store the current floating-point environment in the object pointed to by envp. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feholdexcept(), fesetenv(), feupdateenv(), 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 187 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 57) [tog-c99-xsh 33] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 321 Line: 10119 Section: feholdexcept Problem: Change required for alignment with C99 (ref C99 section 7.6.4.2). Action: Add the following entry after line 10119: NAME feholdexcept - save current floating-point environment SYNOPSIS #include int feholdexcept(fenv_t *envp); 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 feholdexcept() function shall save the current floating-point environment in the object pointed to by envp, clear the floating-point status flags, and then install a non-stop (continue on floating-point exceptions) mode, if available, for all floating-point exceptions. RETURN VALUE The feholdexcept() function shall return zero if and only if non-stop floating-point exception handling was successfully installed. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE feholdexcept should be effective on typical IEC 60559 implementations which have the default non-stop mode and at least one other mode for trap handling or aborting. If the implementation provides only the non-stop mode, then installing the non-stop mode is trivial. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), fesetenv(), feupdateenv(), 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 188 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 49) [tog-c99-xsh 25] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 321 Line: 10199 Section: feclearexcept Problem: Change required for alignment with C99 (ref C99 section 7.6.2.1). Action: Add the following entry after line 10199: NAME feclearexcept - clear floating-point exception SYNOPSIS #include void feclearexcept(int excepts); 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 feclearexcept() function shall clear the supported floating-point exceptions represented by excepts. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetexceptflag(), feraiseexcept(), fesetexceptflag(), fetestexcept(), 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 189 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 50) [tog-c99-xsh 26] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 321 Line: 10199 Section: fegetexceptflag Problem: Change required for alignment with C99 (ref C99 section 7.6.2.2). Action: Add the following entry after line 10199: NAME fegetexceptflag - get floating-point status flags SYNOPSIS #include void fegetexceptflag(fexcept_t *flagp, int excepts); 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 fegetexceptflag() function shall store an implementation-dependent representation of the states of the floating-point status flags indicated by the argument excepts in the object pointed to by the argument flagp. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), feraiseexcept(), fesetexceptflag(), fetestexcept(), 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 190 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 59) [tog-c99-xsh 35] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 322 Line: 10230 Section: feupdateenv Problem: Change required for alignment with C99 (ref C99 section 7.6.4.4). Action: Add the following entry after line 10230: NAME feupdateenv - update floating-point environment SYNOPSIS #include void feupdateenv(const fenv_t *envp); 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 feupdateenv() function shall save the currently raised floating-point exceptions in its automatic storage, install the floating-point environment represented by the object pointed to by envp, and then raise the saved floating-point exceptions. The argument envp shall point to an object set by a call to feholdexcept() or fegetenv(), or equal a floating-point environment macro. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES Hide spurious underflow floating-point exceptions: #include double f(double x) { #pragma STDC FENV_ACCESS ON double result; fenv_t save_env; feholdexcept(&save_env); // compute result if (/* test spurious underflow */) feclearexcept(FE_UNDERFLOW); feupdateenv(&save_env); return result; } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), feholdexcept(), fesetenv(), 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 191 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 58) [tog-c99-xsh 34] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 322 Line: 10230 Section: fesetenv Problem: Change required for alignment with C99 (ref C99 section 7.6.4.3). Action: Add the following entry after line 10230: NAME fesetenv - set floating-point environment SYNOPSIS #include void fesetenv(const fenv_t *envp); 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 fesetenv() function shall establish the floating-point environment represented by the object pointed to by envp. The argument envp shall point to an object set by a call to fegetenv() or feholdexcept(), or equal a floating-point environment macro. Note that fesetenv() merely installs the state of the floating-point status flags represented through its argument, and does not raise these floating-point exceptions. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), feholdexcept(), feupdateenv(), 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 192 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 51) [tog-c99-xsh 27] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 322 Line: 10230 Section: feraiseexcept Problem: Change required for alignment with C99 (ref C99 section 7.6.2.3). Action: Add the following entry after line 10230: NAME feraiseexcept - raise floating-point exception SYNOPSIS #include void feraiseexcept(int excepts); 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 feraiseexcept() function shall raise the supported floating-point exceptions represented by its argument. The order in which these floating-point exceptions are raised is unspecified. Whether the feraiseexcept() function additionally raises the inexact floating-point exception whenever it raises the overflow or underflow floating-point exception is implementation-dependent. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The effect is intended to be similar to that of floating-point exceptions raised by arithmetic operations. Hence, enabled traps for floating-point exceptions raised by this function are taken. RATIONALE Raising overflow or underflow is allowed to also raise inexact because on some architectures the only practical way to raise an exception is to execute an instruction that has the exception as a side effect. Any IEC 60559 operation that raises either overflow or underflow raises inexact as well. The function is not restricted to accept only valid coincident expressions for atomic operations, so the function can be used to raise exceptions accrued over several operations. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), fesetexceptflag(), fetestexcept(), 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 193 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 52) [tog-c99-xsh 28] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 323 Line: 10261 Section: fesetexceptflag Problem: Change required for alignment with C99 (ref C99 section 7.6.2.4). Action: Add the following entry after line 10261: NAME fesetexceptflag - set floating-point status flags SYNOPSIS #include void fesetexceptflag(const fexcept_t *flagp, int excepts); 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 fesetexceptflag() function shall set the floating-point status flags indicated by the argument excepts to the states stored in the object pointed to by flagp. The value of *flagp shall have been set by a previous call to fegetexceptflag() whose second argument represented at least those floating-point exceptions represented by the argument excepts. This function does not raise floating-point exceptions, but only sets the state of the flags. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), feraiseexcept(), fetestexcept(), 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 194 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 55) [tog-c99-xsh 31] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 323 Line: 10261 Section: fesetround Problem: Change required for alignment with C99 (ref C99 section 7.6.3.2). Action: Add the following entry after line 10261: NAME fesetround - set current rounding direction SYNOPSIS #include int fesetround(int round); 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 fesetround() function shall establishe the rounding direction represented by its argument round. If the argument is not equal to the value of a rounding direction macro, the rounding direction is not changed. RETURN VALUE The fesetround() function shall return a zero value if and only if the argument is equal to a rounding direction macro (that is, if and only if the requested rounding direction was established). ERRORS No errors are defined. EXAMPLES Save, set, and restore the rounding direction. Report an error and abort if setting the rounding direction fails. #include #include void f(int round_dir) { #pragma STDC FENV_ACCESS ON int save_round; int setround_ok; save_round = fegetround(); setround_ok = fesetround(round_dir); assert(setround_ok == 0); /* ... */ fesetround(save_round); /* ... */ } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetround(), 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 195 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 53) [tog-c99-xsh 29] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 323 Line: 10261 Section: fetestexcept Problem: Change required for alignment with C99 (ref C99 section 7.6.2.5). Action: Add the following entry after line 10261: NAME fetestexcept - test floating-point exception flags SYNOPSIS #include int fetestexcept(int excepts); 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 fetestexcept() function shall determine which of a specified subset of the floating-point exception flags are currently set. The excepts argument specifies the floating-point status flags to be queried. RETURN VALUE The fetestexcept() function shall return the value of the bitwise OR of the floating-point exception macros corresponding to the currently set floating-point exceptions included in excepts. ERRORS No errors are defined. EXAMPLES Call f if invalid is set, then g if overflow is set: #include /* ... */ { #pragma STDC FENV_ACCESS ON int set_excepts; feclearexcept(FE_INVALID | FE_OVERFLOW); // maybe raise exceptions set_excepts = fetestexcept(FE_INVALID | FE_OVERFLOW); if (set_excepts & FE_INVALID) f(); if (set_excepts & FE_OVERFLOW) g(); /* ... */ } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), feraiseexcept(), fesetexceptflag(), 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 196 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 224) [tog-c99-xsh 198] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 324 Line: 10277 Section: fflush Problem: Change required for alignment with C99 (ref C99 section 7.19.5.2). Action: Change " ... otherwise, it shall return EOF and set errno ..." Change " ... otherwise, it shall set the error indicator for the stream, return EOF and set errno ..." [Ed note: Add to CH The RETURN VALUE section is updated to note that the error indicator shall be set for the stream. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 197 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 256) [tog-c99-xsh 230] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 328 Line: 10396 Section: fgetc Problem: Change required for alignment with C99 (ref C99 section 7.19.7.1). Action: Change "The fgetc( ) function obtains the next byte ..." To " If the end-of-file indicator for the input stream pointed to by stream is not set and a next character is present, the fgetc( ) function obtains the next byte ..." [Ed note: Add to CH The DESCRIPTION is updated to clarify that behavior when the end-of-file indicator for the input stream is not set. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 198 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 257) [tog-c99-xsh 231] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 328 Line: 10405 Section: fgetc Problem: Change required for alignment with C99 (ref C99 section 7.19.7.1). Action: Change "... If the stream is at end-of-file, ..." To "... If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, ..." [Ed note: Add to CH The RETURN VALUE section is updated to note that the error indicator shall be set for the stream. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 199 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 264) [tog-c99-xsh 238] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 331 Line: 10472 Section: fgetpos Problem: Change required for alignment with C99 (ref C99 section 7.19.9.1). Action: Change "int fgetpos(FILE * stream, fpos_t * pos);" To "int fgetpos(FILE * restrict stream, fpos_t * restrict pos);" [Ed note: Add to CH The prototype for fgetpos() is changed for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 200 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 175) [tog-c99-xsh 149] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The floor( ) function ..." To "The floor(), floorf() and floorl() functions ..." Same change on lines 10807 and 10809. _____________________________________________________________________________ Page: 342 Line: 1076 Section: floor Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "The floor( ) function ..." To "The floor family of functions ..." Same change on lines 10807 and 10809. _____________________________________________________________________________ objection Enhancement Request Number 201 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 258) [tog-c99-xsh 232] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 333 Line: 10519 Section: fgets Problem: Change required for alignment with C99 (ref C99 section 7.19.7.2). Action: Change "char *fgets(char * s, int n, FILE * stream);" To "char *fgets(char * restrict s, int n, FILE * restrict stream);" [Ed note: Add to CH The prototype for fgets() is changed for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 202 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 328) [tog-c99-xsh 302] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 337 Line: 10644 Section: fgetws Problem: Change required for alignment with C99 (ref C99 section 7.23.3.2). Action: Change "wchar_t *fgetws(wchar_t * ws, int n, FILE * stream);" To "wchar_t *fgetws(wchar_t * restrict ws, int n, FILE * restrict stream);" [Ed note: Add to CH The prototype for fgetws() is changed for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 203 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 174) [tog-c99-xsh 148] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 342 Line: 10791 Section: floor Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Add after line 10791: float floorf(float x); long double floorl(long double x); [Ed note: Add to CH The floorf() and floorl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 204 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 176) [tog-c99-xsh 150] 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, floor( ) ..." To "Upon successful completion, the floor(), floorf() and floorl() functions ..." _____________________________________________________________________________ Page: 342 Line: 10800 Section: floor Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "Upon successful completion, floor( ) ..." To "Upon successful completion, the floor family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 205 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 203) [tog-c99-xsh 177] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 343 Line: 10837 Section: fmin Problem: Change required for alignment with C99 (ref C99 section 7.12.12.3). Action: Add the following entry after line 10837: NAME fmin - determine minimum numeric value of two floating-point numbers SYNOPSIS #include double fmin(double x, double y); float fminf(float x, float y); long double fminl(long double x, long double y); 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 fmin() functions shall determine the minimum numeric value of their arguments. NaN arguments shall be treated as missing data: if one argument is a NaN and the other numeric, then the fmin() functions shall choose the numeric value. 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 fmin() functions shall return the minimum numeric value of their arguments. If x and y are NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fmin() functions may fail if: [EDOM] The value of x and y is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fdim(), fmax(), 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 206 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 204) [tog-c99-xsh 178] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 343 Line: 10837 Section: fma Problem: Change required for alignment with C99 (ref C99 section 7.12.13.1). Action: Add the following entry after line 10837: NAME fma - floating-point multiply-add SYNOPSIS #include double fma(double x, double y, double z); float fmaf(float x, float y, float z); long double fmal(long double x, long double y, long double 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 fma() functions shall compute (x * y) + z, rounded as one ternary operation: they shall compute the value (as if) to infinite precision and round once to the result format, according to the rounding mode characterized by the value of FLT_ROUNDS. 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 fma() functions shall return (x * y) + z, rounded as one ternary operation. If x, y or z is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fma() functions may fail if: [EDOM] The value of x, y or z is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In many cases, clever use of floating (fused) multiply-add leads to much improved code; but its unexpected use by the compiler can undermine carefully written code. The FP_CONTRACT macro can be used to disallow use of floating multiply-add; and the fma function guarantees its use where desired. Many current machines provide hardware floating multiply-add instructions; software implementation can be used for others. 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 207 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 202) [tog-c99-xsh 176] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 343 Line: 10837 Section: fmax Problem: Change required for alignment with C99 (ref C99 section 7.12.12.2). Action: Add the following entry after line 10837: NAME fmax - determine maximum numeric value of two floating-point numbers SYNOPSIS #include double fmax(double x, double y); float fmaxf(float x, float y); long double fmaxl(long double x, long double y); 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 fmax() functions shall determine the maximum numeric value of their arguments. NaN arguments shall be treated as missing data: if one argument is a NaN and the other numeric, then the fmax() functions shall choose the numeric value. 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 fmax() functions shall return the maximum numeric value of their arguments. If x and y are NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fmax() functions may fail if: [EDOM] The value of x and y is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fdim(), fmin(), 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 208 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 187) [tog-c99-xsh 161] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 344 Line: 10842 Section: fmod Problem: Change required for alignment with C99 (ref C99 section 7.12.10.1). Action: Add after line 10842: float fmodf(float x, float y); long double fmodl(long double x, long double y); [Ed note: Add to CH The fmodf() and fmodl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 209 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 188) [tog-c99-xsh 162] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The fmod( ) function ..." To "The fmod(), fmodf() and fmodl() functions ..." Same change on lines 10852 and 10862. _____________________________________________________________________________ Page: 344 Line: 10847 Section: fmod Problem: Change required for alignment with C99 (ref C99 section 7.12.10.1). Action: Change "The fmod( ) function ..." To "The fmod family of functions ..." Same change on lines 10852 and 10862. _____________________________________________________________________________ Comment Enhancement Request Number 210 donnte@microsoft.com Bug in XSHd3 (rdvk# 500) [DT-XSH-68] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: EMB this is nothing to do with syslog. This function was not considered on the new legacy discussion earlier. _____________________________________________________________________________ Page: 346 Line: 10889 Section: fmtmsg Problem: Given the similar, and much more functional, syslog stuff, does it make sense to continue to give this full status? Minimally, make legacy. Possibly delete. Action: Delete (or make legacy). _____________________________________________________________________________ Comment Enhancement Request Number 211 donnte@microsoft.com Bug in XSHd3 (rdvk# 501) [DT-XSH-69] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: EMB nothing to do with syslog _____________________________________________________________________________ Page: 348 Line: 10093 Section: fmtmsg Problem: If it *is* retained, add syslog (really, closelog, because that's where the real definition is, but see my comments on that) to See Also. Action: Add syslog/closelog to See Also. _____________________________________________________________________________ Comment Enhancement Request Number 212 donnte@microsoft.com Bug in XSHd3 (rdvk# 502) [DT-XSH-70] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the reviewers do not agree with the problem statement. these are two different things _____________________________________________________________________________ Page: 349 Line: 11042 Section: fnmatch Problem: EMB It just finished discussing FNM_PERIOD at 11025. Now it says that periods are always ignored. Action: Change "but without..." -> "but without tilde expansion or parameter expansion, and in the absence of FNM_PERIOD, special treatment for a period at the beginning of a filename." _____________________________________________________________________________ objection Enhancement Request Number 213 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 225) [tog-c99-xsh 199] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 351 Line: 11064 Section: fopen Problem: Change required for alignment with C99 (ref C99 section 7.19.5.3). Action: Change "FILE *fopen(const char * filename, const char * mode);" To "FILE *fopen(const char * restrict filename, const char * restrict mode);" [Ed note: Add to CH The prototype for fopen() is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 214 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 226) [tog-c99-xsh 200] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 351 Line: 11071 Section: fopen Problem: Change required for alignment with C99 (ref C99 section 7.19.5.3). Action: Change "The argument mode points to a string beginning with one of the following sequences:" To "The argument mode points to a string. If the string is one of the following, the file is open in the indicated mode. Otherwise, the behavior is undefined." [Ed note: Add to CH The DESCRIPTION is updated to note that if the argument mode points to a string other than those listed, then the behavior is undefined. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 215 donnte@microsoft.com Bug in XSHd3 (rdvk# 503) [DT-XSH-71] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 11314-11316 _____________________________________________________________________________ Page: 357 Line: 11314 Section: fork Problem: This paragraph is a nonsequeteur. Action: Editors: please find original change request and determine what was intended... did "the requirement" (whatever it was, something to do with signals) get omitted from the insertion or did this text get inserted in the wrong place. (Or is this part of the change at 11225, and the text might want to be: "The original language did not adequately convey that the alarm must be completely canceled.") (If this latter is the case, this rationale is rationale for the change, but not meaningful as permanent rationale, as the change stands alone very nicely. Delete it.) _____________________________________________________________________________ Comment Enhancement Request Number 216 donnte@microsoft.com Bug in XSHd3 (rdvk# 504) [DT-XSH-72] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete line 11346-11348 _____________________________________________________________________________ Page: 358 Line: 11346 Section: fork Problem: This paragraph is now obsolete. Action: 1) Get posix_spawn advocates to rewrite. 2) Lacking that, at least add an editor's note requesting that action. _____________________________________________________________________________ objection Enhancement Request Number 217 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 68) [tog-c99-xsh 44] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 364 Line: 11588 Section: fpclassify Problem: Change required for alignment with C99 (ref C99 section 7.12.3.1). Action: Add the following entry after line 11588: NAME fpclassify - classify real floating type SYNOPSIS #include int fpclassify(real-floating 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 fpclassify() macro shall classify its argument value as NaN, infinite, normal, subnormal, zero, or into another implementation-dependent category. First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then classification is based on the type of the argument. RETURN VALUE The fpclassify() macro shall return the value of the number classification macro appropriate to the value of its argument. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isfinite(), isinf(), isnan(), isnormal(), signbit(), 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 218 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 233) [tog-c99-xsh 207] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 365 Line: 11593-11596 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "int fprintf(FILE * stream, const char * format, ...); int printf(const char * format, ...); int snprintf(char *s, size_t n, const char * format, ...); int sprintf(char *s, const char * format, ...);" To "int fprintf(FILE * restrict stream, const char * restrict format, ...); int printf(const char * restrict format, ...); int snprintf(char * restrict s, size_t n, const char * restrict format, ...); int sprintf(char * restrict s, const char * restrict format, ...);" And remove XSI shading from snprint(). [Ed note: Add to CH The prototypes for fprintf(), printf(), snprintf() and sprintf() are updated for alignment with ISO/IEC 9899:1999 C. The XSI shading is removed from snprintf().] _____________________________________________________________________________ objection Enhancement Request Number 219 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 234) [tog-c99-xsh 208] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 366 Line: 11646-11657 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change lines 11646-11657 to contain only the following text: "* An optional length modifier that specifies the size of the argument." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Comment Enhancement Request Number 220 donnte@microsoft.com Bug in XSHd3 (rdvk# 505) [DT-XSH-73] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Do XSI shading (from 11698->end of para). Quote '0' everywhere in paragraph. Change ''' to '\'' _____________________________________________________________________________ Page: 367 Line: 11699 Section: fprintf Problem: The sentence "If the 0 and..." has two problems: 1) It should be shaded (because ' is an XSI extension) and it makes no sense in the absence of that extension. 2) It needs a minor rewrite for clarity. Action: Shade, replace with: If the 0 and ' flags both appear, grouping characters are inserted before zero padding is performed. (So it's intended that a result like 00000000001,234.00 is produced? If so, that's worth a bit of rationale.) _____________________________________________________________________________ objection Enhancement Request Number 221 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 235) [tog-c99-xsh 209] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 367 Line: 11700 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the following text after line 11700: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x,orXconversion specifier applies to a signed char or unsigned char argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to signed char or unsigned char before printing); or that a following n conversion specifier applies to a pointer to a signed char argument. h Specifies that a following d, i, o, u, x,orXconversion specifier applies to a short int or unsigned short int argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to short int or unsigned short int before printing); or that a following n conversion specifier applies to a pointer to a short int argument. l (ell) Specifies that a following d, i, o, u, x,orXconversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g,orGconversion specifier. ll (ell-ell) Specifies that a following d, i, o, u, x,orXconversion specifier applies to a long long int or unsigned long long int argument; or that a following n conversion specifier applies to a pointer to a long long int argument. j Specifies that a following d, i, o, u, x,orXconversion specifier applies to an intmax_t or uintmax_t argument; or that a following n conversion specifier applies to a pointer to an intmax_t argument. z Specifies that a following d, i, o, u, x,orXconversion specifier applies to a size_t or the corresponding signed integer type argument; or that a following n conversion specifier applies to a pointer to a signed integer type corresponding to size_t argument. t Specifies that a following d, i, o, u, x,orXconversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument; or that a following n conversion specifier applies to a pointer to a ptrdiff_t argument. L Specifies that a following a, A, e, E, f, F, g,orGconversion specifier applies to a long double argument. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 222 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 236) [tog-c99-xsh 210] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 367 Line: 11723 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "f A double argument ..." To "f,F A double argument ..." _____________________________________________________________________________ objection Enhancement Request Number 223 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 237) [tog-c99-xsh 211] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 11728-11729 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-dependent. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) which style, and the meaning of any n-char-sequence, is implementation-dependent. The F conversion specifier produces INF, INFINITY,or NAN instead of inf, infinity,ornan, respectively." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 224 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 238) [tog-c99-xsh 212] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 11737-11738 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 225 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 239) [tog-c99-xsh 213] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 11746-11747 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 226 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 240) [tog-c99-xsh 214] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept___X_ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 368 Line: 11748 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the folowing text after line 11748: a,A A double argument representing a floating-point number is converted in the style [-]0xh.hhhh p1d, where there is one hexadecimal digit (which is nonzero if the argument is a normalized floating-point number and is otherwise unspecified) before the decimal-point character 235) and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision is sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision is sufficient to distinguish 236) values of type double, except that trailing zeros may be omitted; if the precision is zero and the # flag is not specified, no decimal-point character appears. The letters abcdef are used for a conversion and the letters ABCDEF for A conversion. The A conversion specifier produces a number with X and P instead of x and p. The exponent always contains at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier. _____________________________________________________________________________ objection Enhancement Request Number 227 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 241) [tog-c99-xsh 215] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 369 Line: 11779 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "If a conversion specification does not match one of the above forms, the behavior is undefined." To "If a conversion specification does not match one of the above forms, the behavior is undefined. If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined." _____________________________________________________________________________ objection Enhancement Request Number 228 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 242) [tog-c99-xsh 216] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 369 Line: 11783 Section: fprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the following text after line 11783: For a and A conversions, if FLT_RADIX is a power of 2, the value is correctly rounded to a hexadecimal floating number with the given precision. If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction. For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most DECIMAL_DIG, then the result should be correctly rounded. If the number of significant decimal digits is more than DECIMAL_DIG but the source value is exactly representable with DECIMAL_DIG digits, then the result should be an exact representation with trailing zeros. Otherwise, the source value is bounded by two adjacent decimal strings L < U, both having DECIMAL_DIG significant digits; the value of the resultant decimal string D should satisfy L <= D <= U, with the extra stipulation that the error should have a correct sign for the current rounding direction. _____________________________________________________________________________ Objection Enhancement Request Number 229 donnte@microsoft.com Bug in XSHd3 (rdvk# 507) [DT-XSH-75] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 11791 and 11794 should not be shaded. There is no conflict as described, but we should use the C words more: change 11794 to "If the value of n is zero on a call to snprintf( ), nothing shall be written, the number of bytes that would have been written had n been sufficiently large exluding the terminating null shall be returned, and s may be a null pointer." Also l 11595 should be unshaded. _____________________________________________________________________________ Page: 369 Line: 11791 Section: fprintf Problem: I *think* there's a conflict here. On 11791 it says that the return value will be the "virtual n" that would have been used had the string been long enough. However, the left hand taketh away on 11794, in that passing a zero (as opposed to the generally equally useless 1) is unspecified. Action: Change "is zero" to "is less than zero". _____________________________________________________________________________ Objection Enhancement Request Number 230 donnte@microsoft.com Bug in XSHd3 (rdvk# 506) [DT-XSH-74] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_229 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 369 Line: 11794 Section: fprintf Problem: "unspecified shall be returned" is nonsensical. (So was the probable "unspecified will be returned" that it was before.) It should be... Action: "...the return value is unspecified". _____________________________________________________________________________ comment Enhancement Request Number 231 drepper@redhat.com Bug in XSHd3 (rdvk# 413) {ud-55} Sun, 30 Apr 2000 10:44:47 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 370 Line: 11846-11854 Section: fprintf() Problem: This example code in the rational is quite poor. It assumes certain sizes for the types used for the st_uid, st_gid, and st_size fields of `struct stat'. This is precise code which some people actually write and which breaks once in a while. There is no guarantee that st_uid and st_gid are of type int or a smaller one and there are definitely cases where st_size values do not fit into a long int (e.g., when compiling with _FILE_OFFSET_BITS=64). Action: Replace lines 11846 to 11854 of the example with: if ((pwd = getpwuid (statbuf.st_uid)) != NULL) printf (" %-8.8s", pwd->pw_name); else printf (" %-8ld", (long int) statbuf.st_uid); if ((grp = getgrgid (statbuf.st_gid)) != NULL) printf (" %-8.8s", grp->gr_name); else printf (" %-8ld", (long int) statbuf.st_gid); printf ("%9jd", (intmax_t) statbuf.st_size); This is still not perfect but it will at least work in all situations known to me. Please note that the last printf() uses ISO C99 features which we most probably be introduced in the next revision of the draft. _____________________________________________________________________________ objection Enhancement Request Number 232 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 259) [tog-c99-xsh 233] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 378 Line: 12126 Section: fputs Problem: Change required for alignment with C99 (ref C99 section 7.19.7.4). Action: Change "int fputs(const char * s, FILE * stream);" To "int fputs(const char * restrict s, FILE * restrict stream);" [Ed note: Add to CH The fputs() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ comment Enhancement Request Number 233 Sandra O Bug in XSHd3 (rdvk# 371) [compaq-smo-001] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: (see also 83) this would open up other holes (such as the conversion of EOF). Lots of controversy. _____________________________________________________________________________ Page: 380 Line: 12187-12188 Section: fputwc Problem: The Description does not make clear that the wide-character code wc gets converted. Action: Change "The fputwc() function shall write the character coresponding to the wide-character code wc to the output stream pointed to by stream,..." to "The fputwc() function shall convert the wide-character code wc to the corresponding character and write it to the output stream pointed to by stream,..." This uses similar languge to that in fgetwc(), and makes the conversion clear. _____________________________________________________________________________ Editorial Enhancement Request Number 234 donnte@microsoft.com Bug in XSHd3 (rdvk# 508) [DT-XSH-76] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 380 Line: 12191 Section: fputwc Problem: American English (or is that an oxymoron? :-) ) Action: "whilst" -> "while" _____________________________________________________________________________ objection Enhancement Request Number 235 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 329) [tog-c99-xsh 303] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 382 Line: 12257 Section: fputws Problem: Change required for alignment with C99 (ref C99 section 7.23.3.4). Action: Change "int fputws(const wchar_t * ws, FILE * stream);" To "int fputws(const wchar_t * restrict ws, FILE * restrict stream);" [Ed note: Add to CH The fputws() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 236 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 260) [tog-c99-xsh 234] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 383 Line: 12294 Section: fread Problem: Change required for alignment with C99 (ref C99 section 7.19.8.1). Action: Change "size_t fread(void * ptr, size_t size, size_t nitems, FILE * stream);" To "size_t fread(void * restrict ptr, size_t size, size_t nitems, FILE * restrict stream);" [Ed note: Add to CH The fread() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 237 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 261) [tog-c99-xsh 235] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 383 Line: 12300 Section: fread Problem: Change required for alignment with C99 (ref C99 section 7.19.8.1). Action: Change ".., from the stream pointed to by stream. ..." To ".., from the stream pointed to by stream. For each object, size calls are made to the fgetc() function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object. ..." [Ed note: Add to CH The DESCRIPTION is updated to describe how the bytes from a call to fgetc are stored. This change is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 238 prindle@voicenet.com Bug in XSHd3 (rdvk# 645) [prindle.xsh-15] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 385 Line: 12360 Section: free() Problem: This line is inconsistent with page 837, line 26157-26158, section posix_memalign(). Specifically, it should allow posix_memalign() in the set of functions that may have returned the pointer to storage to be freed. Action: Add posix_memalign() to the 3 functions listed here. This is not a POSIX.1 interpretation issue, as POSIX.1 does not define the semantics of free() other than in .1d (posix_memalign()). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 239 donnte@microsoft.com Bug in XSHd3 (rdvk# 509) [DT-XSH-77] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use "results in" as in "results in undefined behavior" (global edit) _____________________________________________________________________________ Page: 385 Line: 12362 Section: free Problem: shall...undefined again. Action: "It is an undefined operation to access a pointer to freed space." There really is a meaning difference between "shall...undefined" and "is undefined": in the first case, you're requiring that the system do something undefined (maybe something random or irrational). In the second case, it simply says doing so is undefined (but allows room for someone else to define it). Thus... look everywhere for "shall...undefined" and rephrase to allow the possibility of someone else defining it. (In this case, a system extension providing a diagnostic would be a very good thing!). _____________________________________________________________________________ comment Enhancement Request Number 240 al.simons@compaq.com Bug in XSHd3 (rdvk# 427) {compaq-aks-032} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Editorial comment: in the quoted passages, the word "successful" is unnecessary, so delete "successful" _____________________________________________________________________________ Page: 387 Line: 12414-12415 Section: freeaddrinfo also at page 388 line 12467-12468 Problem: The description states in these two sections that "in the absence of errors one or more successful results shall be returned" (page 387) and "in the absence of errors, all possible successful results shall be returned" (page 388). It does not state what happens in the event of an error, particularly whether the partial results that were successfully obtained before the error are returned. Action: Add a sentence at line 12415 and 12468 indicating the failure case. Editorial comment: in the quoted passages, the word "successful" is unnecessary, as it is preceded by the phrase, "in the absence of errors". _____________________________________________________________________________ Comment Enhancement Request Number 241 donnte@microsoft.com Bug in XSHd3 (rdvk# 510) [DT-XSH-78] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_242 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 387 Line: 12421 Section: freeaddrinfo Problem: "REFERENCE UNDEFINED" Action: Fix reference coding. _____________________________________________________________________________ editorial Enhancement Request Number 242 ajosey@rdg.opengroup.org Bug in XSHd3 (rdvk# 1) {tog-001} Thu, 2 Mar 2000 15:08:12 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 387 Line: 12421 Section: freeaddrinfo Problem: This is an editorial issue: There is an undefined reference to inet_pton The same problem occurs on page 478 line 15365 Action: Editorial fix. _____________________________________________________________________________ editorial Enhancement Request Number 243 al.simons@compaq.com Bug in XSHd3 (rdvk# 426) {compaq-aks-031} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_242 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 387 Line: 12421 Section: freeaddrinfo Problem: There is a reference to an undefined tag: "(inet_pton)" Action: Define the needed reference. _____________________________________________________________________________ objection Enhancement Request Number 244 al.simons@compaq.com Bug in XSHd3 (rdvk# 425) {compaq-aks-030} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 389 Line: 12499 Section: freeaddrinfo Problem: freeaddrinfo() returns void, but is listed as returning errors. The errors listed refer only to getaddrinfo(). Action: Remove the words "freeaddrinfo() and" from line 12499. _____________________________________________________________________________ objection Enhancement Request Number 245 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 227) [tog-c99-xsh 201] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 392 Line: 12541 Section: freopen Problem: Change required for alignment with C99 (ref C99 section 7.19.5.4). Action: Change "FILE *freopen(const char * filename, const char * mode, FILE * stream);" To "FILE *freopen(const char * restrict filename, const char * restrict mode, FILE * restrict stream);" [Ed note: Add to CH The freopen() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 246 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 228) [tog-c99-xsh 202] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 392 Line: 12551 Section: freopen Problem: Change required for alignment with C99 (ref C99 section 7.19.5.4). Action: Add the following text after line 12551: If filename is a null pointer, the freopen() function shall attempt to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used. It is implementation-dependent which changes of mode are permitted (if any), and under what circumstances. [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 247 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 117) [tog-c99-xsh 93] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 395 Line: 12661 Section: frexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Add after line 12661: float frexpf(float value, int *exp); long double frexpl(long double value, int *exp); [Ed note: Add to CH The frexpf() and frexpl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 248 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 118) [tog-c99-xsh 94] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The frexp( ) function ..." To "The frexp(), frexpf() and frexpl() functions ..." Same change on lines 12671 and 12679. _____________________________________________________________________________ Page: 395 Line: 12666 Section: frexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Change "The frexp( ) function ..." To "The frexp family of functions ..." Same change on lines 12671 and 12679. _____________________________________________________________________________ objection Enhancement Request Number 249 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 119) [tog-c99-xsh 95] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The frexp( ) function shall return the value x, such that x is a double with magnitude in the ..." To "The frexp(), frexpf() and frexpl() functions shall return the value x, such that x has a magnitude in the ..." _____________________________________________________________________________ Page: 395 Line: 12671 Section: frexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Change "The frexp( ) function shall return the value x, such that x is a double with magnitude in the ..." To "The frexp family of functions shall return the value x, such that x has a magnitude in the ..." _____________________________________________________________________________ objection Enhancement Request Number 250 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 244) [tog-c99-xsh 218] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 398-399 Line: 12745-12755 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change lines 12745-12755 to contain only the following text: "* An optional length modifier that specifies the size of the receiving object." _____________________________________________________________________________ Editorial Enhancement Request Number 251 donnte@microsoft.com Bug in XSHd3 (rdvk# 511) [DT-XSH-79] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 399 Line: 12762 Section: fscanf Problem: need comma Action: "character which" -> "character, which". _____________________________________________________________________________ Editorial Enhancement Request Number 252 donnte@microsoft.com Bug in XSHd3 (rdvk# 512) [DT-XSH-80] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 399 Line: 12764 Section: fscanf Problem: Need colon? Normally "as follows" is followed by a colon. Action: "as follows." -> "as follows:". _____________________________________________________________________________ objection Enhancement Request Number 253 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 246) [tog-c99-xsh 220] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 399 Line: 12767 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text to the end of line 12767: Similarly, if end-of-file, an encoding error, or a read error prevents a character from being read, the directive fails. [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 254 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 245) [tog-c99-xsh 219] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 399 Line: 12789 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text after line 12789: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to signed char or unsigned char. h Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to short int or unsigned short int. l (ell) Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to long int or unsigned long int; that a following a, A, e, E, f, F, g,or G conversion specifier applies to an argument with type pointer to double; or that a following c, s,or[ conversion specifier applies to an argument with type pointer to wchar_t. ll (ell-ell) Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to long long int or unsigned long long int. j Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to intmax_t or uintmax_t. z Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to size_t or the corresponding signed integer type. t Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to ptrdiff_t or the corresponding unsigned integer type. L Specifies that a following a, A, e, E, f, F, g,or G conversion specifier applies to an argument with type pointer to long double. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 255 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 247) [tog-c99-xsh 221] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 400 Line: 12811 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "e,f g Matches an optionally signed floating-point number, whose format is the same as ..." To "a,e,f g Matches an optionally signed floating-point number, infinity or NaN, whose format is the same as ..." _____________________________________________________________________________ Editorial Enhancement Request Number 256 donnte@microsoft.com Bug in XSHd3 (rdvk# 513) [DT-XSH-81] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove the 7858 _____________________________________________________________________________ Page: 400 Line: 12815 Section: fscanf Problem: What is a "7858". Action: Delete "7858" or replace with whatever was intended. _____________________________________________________________________________ objection Enhancement Request Number 257 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 248) [tog-c99-xsh 222] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 401 Line: 12875 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text to the end of line 12875: No argument is converted, but one is consumed. If the conversion specification includes an assignment-suppressing character or a field width, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 258 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 249) [tog-c99-xsh 223] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 401 Line: 12881 Section: fscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "The conversion characters E, G, and X are also valid and behave the same as, respectively, e, g, and x." To "The conversion characters A, E, F, G and X are also valid and behave the same as, respectively, a, e, f, g, and x." _____________________________________________________________________________ objection Enhancement Request Number 259 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 265) [tog-c99-xsh 239] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 405 Line: 12993 Section: fseek Problem: Change required for alignment with C99 (ref C99 section 7.19.9.2). Action: Change "The fseek( ) function shall set the file-position indicator for the stream pointed to by stream." To "The fseek( ) function shall set the file-position indicator for the stream pointed to by stream. If a read or write error occurs, the error indicator for the stream shall be set and fseek() fails. [Ed note: Add to CH The DESCRIPTION is updated to to explicitly state that fseek() sets the file-position indicator, and than on error the error indicator is set and fseek() fails. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 260 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 266) [tog-c99-xsh 240] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 408 Line: 13113 Section: fsetpos Problem: Change required for alignment with C99 (ref C99 section 7.19.9.3). Action: Add the following statement to the end of line 13113: If a read or write error occurs, the error indicator for the stream shall be set and fsetpos() fails. [Ed note: Add to CH The DESCRIPTION is updated to clarify that the error indicator is set for the stream on a read or write error. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 261 donnte@microsoft.com Bug in XSHd3 (rdvk# 514) [DT-XSH-82] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: lseek clearly states this imp defined. Add an imp defined statement to fsetpos() at end of description, using fseek() words as template. _____________________________________________________________________________ Page: 408 Line: 13123 Section: fsetpos Problem: If the file being operated upon is a tty (or other non-seekable device other than those listed here) what error is returned? The lseek() function has the same problem, and the same solution should apply. From a sample of one, no error is returned. Action: If implementations generally agree that lseek() on a tty is a benign no-op, then a note both here and lseek is justified. Consider adding text: For unseekable devices other than those listed with ESPIPE, shall return without an error, having done nothing. _____________________________________________________________________________ Objection Enhancement Request Number 262 donnte@microsoft.com Bug in XSHd3 (rdvk# 515) [DT-XSH-83] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At L13253, delete everything after required .... Note stat uses the same text (aarvark comment notwithstanding) and the same applies there. _____________________________________________________________________________ Page: 412 Line: 13253 Section: fstatvfs Problem: This is the only similar function (e.g. stat, chmod) that makes a statement about the pathname leading to the directory. 1) Why is it needed here and not elsewhere (or vice versa). 2) The requirement is actually rather excessive. It says that a conforming application must either visit or otherwise know that all the components of the pathname are searchable. Personally, I have no intent of walking the tree in every such call to ensure something that the system will check for me anyway. (Many fixes for "musts" ended up with "the application shall ensure", literally (not as simply a thought process as I suggested at one point) introducing unintended additional requirements on conforming applications.) The "application shall assure" problem is actually much deeper than I initially realized. The original "shall" didn't explicitly specify who was responsible to make the check. The conversion to "must" did make it explicit that it was the application, and "application shall ensure" makes that even clearer. However, if thought about VERY carefully, it's actually a requirement on the *implementation*. The implementation is required to either return an error or succeed. One of the errors it's required to return is that the directory is not empty. Thus I claim it's a shall on the implementation. (And, in general, most former "must"s are good candidates to have this same problem.) Action: Delete. _____________________________________________________________________________ editorial Enhancement Request Number 263 ajosey@opengroup.org Bug in XSHd3 (rdvk# 16) {ftime-ch} Tue, 11 Apr 2000 09:48:10 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 420 Line: 13496 Section: ftime Problem: This is a dup of PWF20000411, calling out the page and line numbers. There is a typo in the change history, "1980" ought to be "1970" Action: Change "1980" on line 13496 to "1970" The same change is need on getdate: page 461 line 14828 gettimeofday: page 545 line 17328 _____________________________________________________________________________ Objection Enhancement Request Number 264 donnte@microsoft.com Bug in XSHd3 (rdvk# 516) [DT-XSH-84] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete shading on synopsis. Delete L 13588. Correct shading (the markup copy has it) _____________________________________________________________________________ Page: 423 Line: 13571 Section: ftruncate Problem: ftruncate is always required (in .1a, as of D13 anyway). The fact that MF/SHM got there first for it to apply to their special file types is nice, but it should be always required for regular files. (Or hasn't .1a been included yet?) Action: Remove shading, and add MF or SHM if needed elsewhere in the page. (e.g. 13625) _____________________________________________________________________________ Objection Enhancement Request Number 265 donnte@microsoft.com Bug in XSHd3 (rdvk# 517) [DT-XSH-85] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "to a maximum of 10 levels deep" to "using at most 10 file descriptors" _____________________________________________________________________________ Page: 427 Line: 13712 Section: ftw Problem: That's not what ndirs means (I think). Nowhere that I can find does ndirs change the external behavior of ftw (it walks as deep as it needs to) (at least in this document). It simply specifies how much of a particular resource the implementation can use to be more efficient. Action: Either change "to a maximum of 10 levels deep" to "using at most 10 file descriptors", or change the description of ndirs to limit the depth of search. (And I believe I'd find the latter objectionable in itself.) _____________________________________________________________________________ objection Enhancement Request Number 266 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 309) [tog-c99-xsh 283] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 431 Line: 13815-13817 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "int fwprintf(FILE * stream, const wchar_t * format, ...); int swprintf(wchar_t *s, size_t n, const wchar_t * format, ...); int wprintf(const wchar_t * format, ...);" To "int fwprintf(FILE * restrict stream, const wchar_t * restrict format, ...); int swprintf(wchar_t * restrict ws, size_t n, const wchar_t * restrict format, ...); int wprintf(const wchar_t * restrict format, ...);" [Ed note: Add to CH The prototypes for fwprintf(), swprintf(), and wprintf() are updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 267 Sandra O Bug in XSHd3 (rdvk# 372) [compaq-smo-002] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The first part is covered in 266 above, Line 13824 in the Description also needs to be updated (change "...the null wide character in consecutive wide characters starting at *s..." to "...the null wide character in consecutive wide characters starting at *ws..."). _____________________________________________________________________________ Page: 431 Line: 13816 Section: fwprintf Problem: The swprintf() synopsis uses "s" to refer to a wide character string parameter. Action: Change the synopsis for swprintf() from: int swprintf (wchar_t *s, size_t n, const wchar_t format, ...); to: int swprintf (wchar_t *ws, size_t n, const wchar_t format, ...); Most other wide character string parameters are called "ws", rather than "s" (see fgetws(), fputws(), wcscoll(), wcscpy(), etc.). Since most developers think of "s" as referring to a string of char's, it is misleading to use "s" here to refer to wchar_t's. If that change is adopted, Line 13824 in the Description also needs to be updated (change "...the null wide character in consecutive wide characters starting at *s..." to "...the null wide character in consecutive wide characters starting at *ws..."). _____________________________________________________________________________ objection Enhancement Request Number 268 Sandra O Bug in XSHd3 (rdvk# 373) [compaq-smo-003] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 431 Line: 13844 Section: fwprintf Problem: Radix character is not language-dependent. Action: Change "All forms of the fwprintf() functions allow for the insertion of a language-dependent radix character. . ." to "All forms of the fwprintf() function allow for the insertion of a locale-dependent radix character. . ." Radix characters are a feature of a locale rather than a language. In a French-for-France locale, the comma (,) is the decimal separator; in a French-for-Switzerland locale, the period (.) is the decimal separator. The language is the same, but the character differs. _____________________________________________________________________________ objection Enhancement Request Number 269 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 310) [tog-c99-xsh 284] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 432 Line: 13862-13874 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change lines 13862-13874 to contain only the following text: "* An optional length modifier that specifies the size of the argument." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ comment Enhancement Request Number 270 Sandra O Bug in XSHd3 (rdvk# 374) [compaq-smo-004] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 432 Line: 13896 Section: fwprintf Problem: Unclear wording about grouping characters. Action: Change "The non-monetary grouping wide character is used." to "The numeric grouping wide character is used." Rather than forcing readers to figure out what the "non-monetary grouping character" is, it's clearer to tell them. _____________________________________________________________________________ objection Enhancement Request Number 271 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 311) [tog-c99-xsh 285] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 433 Line: 13918 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add the following text after line 13918: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x,or X conversion specifier applies to a signed char or unsigned char argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to signed char or unsigned char before printing); or that a following n conversion specifier applies to a pointer to a signed char argument. h Specifies that a following d, i, o, u, x,or X conversion specifier applies to a short int or unsigned short int argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to short int or unsigned short int before printing); or that a following n conversion specifier applies to a pointer to a short int argument. l (ell) Specifies that a following d, i, o, u, x,or X conversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g,orGconversion specifier. ll (ell-ell) Specifies that a following d, i, o, u, x,or X conversion specifier applies to a long long int or unsigned long long int argument; or that a following n conversion specifier applies to a pointer to a long long int argument. j Specifies that a following d, i, o, u, x, or X conversion specifier applies to an intmax_t or uintmax_t argument; or that a following n conversion specifier applies to a pointer to an intmax_t argument. z Specifies that a following d, i, o, u, x,orXconversion specifier applies to a size_t or the corresponding signed integer type argument; or that a following n conversion specifier applies to a pointer to a signed integer type corresponding to size_t argument. t Specifies that a following d, i, o, u, x,or X conversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument; or that a following n conversion specifier applies to a pointer to a ptrdiff_t argument. L Specifies that a following a, A, e, E, f, F, g,or G conversion specifier applies to a long double argument. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 272 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 312) [tog-c99-xsh 286] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 433 Line: 13942 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "f A double argument ..." To "f,F A double argument ..." _____________________________________________________________________________ objection Enhancement Request Number 273 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 313) [tog-c99-xsh 287] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 433 Line: 13947-13948 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-dependent. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) which style, and the meaning of any n-char-sequence, is implementation-dependent. The F conversion specifier produces INF, INFINITY,orNAN instead of inf, infinity,ornan, respectively." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 274 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 314) [tog-c99-xsh 288] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 434 Line: 13956-13957 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 275 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 315) [tog-c99-xsh 289] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 434 Line: 13965-13966 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. _____________________________________________________________________________ objection Enhancement Request Number 276 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 316) [tog-c99-xsh 290] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 434 Line: 13966 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add the folowing text after line 13966: a,A A double argument representing a floating-point number is converted in the style [-]0xh.hhhh p1d, where there is one hexadecimal digit (which is nonzero if the argument is a normalized floating-point number and is otherwise unspecified) before the decimal-point character 235) and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision is sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision is sufficient to distinguish 236) values of type double, except that trailing zeros may be omitted; if the precision is zero and the # flag is not specified, no decimal-point character appears. The letters abcdef are used for a conversion and the letters ABCDEF for A conversion. The A conversion specifier produces a number with X and P instead of x and p. The exponent always contains at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier. _____________________________________________________________________________ objection Enhancement Request Number 277 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 317) [tog-c99-xsh 291] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 434 Line: 13990 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "No argument is converted." To "No argument is converted. No argument is converted, but one is consumed. If the conversion specification includes any flags, a field width, or a precision, the behavior is undefined." _____________________________________________________________________________ objection Enhancement Request Number 278 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 318) [tog-c99-xsh 292] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 435 Line: 13999 Section: fwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add after line 13999: For a and A conversions, if FLT_RADIX is a power of 2, the value is correctly rounded to a hexadecimal floating number with the given precision. If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction. For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most DECIMAL_DIG, then the result should be correctly rounded. If the number of significant decimal digits is more than DECIMAL_DIG but the source value is exactly representable with DECIMAL_DIG digits, then the result should be an exact representation with trailing zeros. Otherwise, the source value is bounded by two adjacent decimal strings L < U, both having DECIMAL_DIG significant digits; the value of the resultant decimal string D should satisfy L <= D <= U, with the extra stipulation that the error should have a correct sign for the current rounding direction. _____________________________________________________________________________ objection Enhancement Request Number 279 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 262) [tog-c99-xsh 236] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 437 Line: 14049 Section: fwrite Problem: Change required for alignment with C99 (ref C99 section 7.19.8.2). Action: Change "size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE * stream);" To "size_t fwrite(const void * restrict ptr, size_t size, size_t nitems, FILE * restrict stream);" [Ed note: Add to CH The fwrite() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 280 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 263) [tog-c99-xsh 237] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 437 Line: 14056 Section: fwrite Problem: Change required for alignment with C99 (ref C99 section 7.19.8.2). Action: Change ".., to the stream pointed to by stream. ..." To ".., to the stream pointed to by stream. For each object, size calls are made to the fputc() function, taking the values (in order) from an array of unsigned char exactly overlaying the object. ..." [Ed note: Add to CH The DESCRIPTION is updated clarifying how the data is written out using fputc. This is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 281 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 319) [tog-c99-xsh 293] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 439 Line: 14098-14100 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "int fwscanf(FILE * stream, const wchar_t * format, ... ); int swscanf(const wchar_t * s, const wchar_t * format, ... ); int wscanf(const wchar_t * format, ... );" To "int fwscanf(FILE * restrict stream, const wchar_t * restrict format, ... ); int swscanf(const wchar_t * restrict ws, const wchar_t * restrict format, ... ); [Ed note: Add to CH The prototypes for fwscanf() and swscanf() are updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 282 Sandra O Bug in XSHd3 (rdvk# 375) [compaq-smo-005] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The first part of the change below is in 281 above Line 14106 in the Description needs to be updated (change "...the swscanf() function reads from the wide-character string s..." to "...the swscanf() function reads from the wide-character string ws..."). _____________________________________________________________________________ Page: 439 Line: 14099 Section: fwscanf Problem: The swscanf() synopsis uses "s" to refer to a wide character string parameter. Action: Change the synopsis for swscanf() from: int swscanf (const wchar_t *s, const wchar_t format, ...); to: int swscanf (const wchar_t *ws, const wchar_t format, ...); Most other wide character string parameters are called "ws", rather than "s" (see fgetws(), fputws(), wcscoll(), wcscpy(), etc.). Since most developers think of "s" as referring to a string of char's, it is misleading to use "s" here to refer to wchar_t's. If that change is adopted, Line 14106 in the Description also needs to be updated (change "...the swscanf() function reads from the wide-character string s..." to "...the swscanf() function reads from the wide-character string ws..."). _____________________________________________________________________________ objection Enhancement Request Number 283 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 320) [tog-c99-xsh 294] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 439-440 Line: 14134-14144 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change lines 14134-14144 to contain only the following text: "* An optional length modifier that specifies the size of the receiving object." _____________________________________________________________________________ objection Enhancement Request Number 284 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 321) [tog-c99-xsh 295] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 440 Line: 14156 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add to the end of line 14156: Similarly, if end-of-file, an encoding error, or a read error prevents a wide character from being read, the directive fails. _____________________________________________________________________________ objection Enhancement Request Number 285 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 322) [tog-c99-xsh 296] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 440 Line: 14178 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add the following text after line 14178: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to signed char or unsigned char. h Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to short int or unsigned short int. l (ell) Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to long int or unsigned long int; that a following a, A, e, E, f, F, g,orGconversion specifier applies to an argument with type pointer to double; or that a following c, s,or[ conversion specifier applies to an argument with type pointer to wchar_t. ll (ell-ell) Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to long long int or unsigned long long int. j Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to intmax_t or uintmax_t. z Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to size_t or the corresponding signed integer type. t Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to ptrdiff_t or the corresponding unsigned integer type. L Specifies that a following a, A, e, E, f, F, g,orGconversion specifier applies to an argument with type pointer to long double. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 286 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 323) [tog-c99-xsh 297] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 441 Line: 14200 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "e,f g Matches an optionally signed floating-point number, whose format is the same as ..." To "a,e,f g Matches an optionally signed floating-point number, infinity or NaN, whose format is the same as ..." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ comment Enhancement Request Number 287 Sandra O Bug in XSHd3 (rdvk# 376) [compaq-smo-006] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change lines 14238-14244 to: Matches a sequence of wide characters of exactly the number specified by the field width (1 if no field width is present in the conversion specification). If no l length modifier is present, characters from the input field are converted as if by repeated calls to the wcrtomb function, with the conversion state described by an mbstate_t object initialized to zero before the first wide character is converted. The corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence. No null character is added. If an l length modifier is present, the corresponding argument shall be a pointer to the initial element of an array of wchar_t large enough to accept the sequence. No null wide character is added. _____________________________________________________________________________ Page: 442 Line: 14245-14246 Section: fwscanf Problem: Unclear language regarding c format descriptor. Action: The lines state: "Otherwise, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence." It's not obvious what "Otherwise" refers to in this sentence. I recommend using the parallel language from fwprintf() (see Lines 13970 and 13979) as follows: "If an l (ell) qualifier is present, the application shall ensure. . ." _____________________________________________________________________________ objection Enhancement Request Number 288 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 324) [tog-c99-xsh 298] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 442 Line: 14259 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add to the end of line 14259: No argument is converted, but one is consumed. If the conversion specification includes an assignment-suppressing wide character or a field width, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 289 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 325) [tog-c99-xsh 299] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 442 Line: 14265 Section: fwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "The conversion characters E, G, and X are also valid and behave the same as, respectively, e, g, and x." To "The conversion characters A, E, F, G and X are also valid and behave the same as, respectively, a, e, f, g, and x." _____________________________________________________________________________ Objection Enhancement Request Number 290 donnte@microsoft.com Bug in XSHd3 (rdvk# 518) [DT-XSH-86] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add to 14618 "in portable applications" (at end). Add at 14616 (beginning) "On some implementations ...". Move App Usage (as modified) to Rationale replacing 14632-3. At 14587 change undefined to unspecified. _____________________________________________________________________________ Page: 454 Line: 14587 Section: getcwd Problem: At 14587 it says the behavior with a null buf argument is undefined. In Application usage at 14616 you give this undefined behavior a definition. You can't do that in Application Usage. Action: Delete. _____________________________________________________________________________ objection Enhancement Request Number 291 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 366) {drb-010} Tue, 25 Apr 2000 13:28:13 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: since applications can store pointers to the env at any point in their lifetime, creating a thread safe func that modifies the env cannot work. The env is per process, not per thread. No re-entrant version of getenv is needed. It is already stated that getenv is not thread safe. _____________________________________________________________________________ Page: 463 Line: 14872 Section: getenv 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. In the response to POSIX 1003.1 interpretation request #39, the POSIX interpretations committee concurred that the functions getenv_r(), localeconv_r(), and strerror_r() had been inadvertently omitted from the standard, and recommended that they be added to a future revision. XSH6D3 should be that future revision. I am going to submit 3 separate bugs to cover this interpretation, one containing each of three proposed new man pages, rather than submit one annoyingly large bug containing all three. (The preceding header text will appear in all 3 for reference.) Action: Add getenv_r() to the getenv() man page: NAME getenv, getenv_r - get value of an environment variable SYNOPSIS #include char *getenv(const char *name); int getenv_r(const char *name, char *getenvbuf, size_t buflen); DESCRIPTION The functionality described for getenv() in this reference page is aligned with the ICO C standard. Any conflict between the requirements described here and the ICO C standard is unintentional. This volume of IEEE Std 1003.1-200x defers to the ISO C standard. The getenv() function searches the environment list for a string of the form "name=value", and returns a pointer to a string containing the value for the specified name. If the specified name cannot be found, a null pointer is returned. The string pointed to must not be modified by the application, but may be overwritten by a subsequent call to getenv(), setenv(), unsetenv(), or putenv() but will not be overwritten by a call to any other function in this document. This interface need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. The getenv_r() function searches the environment list for a string of the form "name=value", and returns the string containing the value for the specified name in the buffer pointed to by getenvbuf, with length buflen. RETURN VALUE Upon successful completion, getenv() returns a pointer to a string containing the value for the specified name. If the specified name cannot be found a null pointer is returned. The return value from getenv() may point to static data which may be overwritten by subsequent calls to getenv(), setenv(), unsetenv(), or putenv(). Upon successful completion, getenv_r() returns 0. Otherwise, an error number is returned to indicate the error. ERRORS No errors are defined for getenv(). The strerror_r() function may fail if: [ENOENT] The string name was not found in the environment. [ERANGE] Insufficient storage was supplied via getenvbuf and buflen to contain the value for the specified name. EXAMPLES Getting the Value of an Environment Variable The following examples gets the value of the HOME environment variable. Using getenv: #include ... const char *name = "HOME"; char *value; value = getenv (name); Using getenv_r: #include ... #define HOME_MAX 128 const char *name = "HOME"; char value[HOME_MAX]; int status; status = getenv_r (name, value, HOME_MAX); APPLICATION USAGE None. FUTURE DIRECTIONS None. SEE ALSO exec, putenv(), , the XBD specification, Environment Variables . DERIVATION Derived from Issue 1 of the SVID. _____________________________________________________________________________ Objection Enhancement Request Number 292 donnte@microsoft.com Bug in XSHd3 (rdvk# 519) [DT-XSH-87] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change to The clearenv func was considered and rejected. The putenv function has now been included for alignment with the SUS. _____________________________________________________________________________ Page: 463 Line: 14883 Section: getenv Problem: EMB Putenv is defined here, and then the rationale at 14908 says it isn't. Action: "were considered" -> "were originally considered" (or clean up even more thoroughly). _____________________________________________________________________________ Objection Enhancement Request Number 293 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 626) [DWC-37] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 472 Line: 15183 Section: getgrnam Problem: (getgrnam(): [EMFILE] error) "{OPEN_MAX}" is not an errno value. Action: Change P472, L15183 from: {OPEN_MAX} file descriptors are currently open in the calling process. to: [EMFILE] {OPEN_MAX} file descriptors are currently open in the calling process. ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 294 al.simons@compaq.com Bug in XSHd3 (rdvk# 418) {compaq-aks-021} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At line 15251-15252 delete the last sentence of the paragraph, as the case it is calling out cannot be true. At line 15258-15259 reword the error condition to read: [EINVAL] The gidsetsize argument is non-zero and less than the number of group IDs that would have been returned. _____________________________________________________________________________ Page: 475 Line: 15251,15258,15268 Section: getgroups Problem: The getgroups() specification is still inconsistent around the number of groups, partly due to the decision to let the effective group be included on a per-implementation basis. This shows up in several places: Line 15252 includes the phrase, "...and {NGROUPS_MAX} is zero,..." but line 15309 states that the value may not be zero as a FIPS requirement, and the XBD document, on lines 9536-9538, states that the minimum acceptable value is 8. Line 15258 mandates (shall fail) that the function return EINVAL if the gidsetsize is less than OR EQUAL TO the number of supplementary group IDs. In an implementation that does not return the effective group ID, there is no need to fail if the array size equals the number of supplementary group IDs. Line 15268 in the example declares an array of _POSIX_NGROUPS_MAX, but the XBD tells programmers (line 9507) that the value NGROUPS_MAX is the minimum and that the actual value should be obtained via a call to sysconf(_SC_NGROUPS_MAX). In addition, XBD defines _POSIX_NGROUPS_MAX to have a value of 0, so the example is not legal C. This problem also appears at line 15270. Action: At line 15251-15252 delete the last sentence of the paragraph, as the case it is calling out cannot be true. At line 15258-15259 reword the error condition to read: [EINVAL] The gidsetsize argument is non-zero and less than the number of group IDs that would have been returned. At line 15268-15270 rework the example to use sysconf(). _____________________________________________________________________________ Objection Enhancement Request Number 295 donnte@microsoft.com Bug in XSHd3 (rdvk# 520) [DT-XSH-88] 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 believed to be a problem. _____________________________________________________________________________ Page: 477 Line: 15315 Section: gethostbyaddr Problem: Indexing a page which has a mixture of legacy and non legacy interfaces by the name of a legacy one seems risky. (If the legacy interface is ever deleted, the page will move.) Action: Index by the first non-legacy interface name (or as noted elsewhere, by the most meaningful name, which almost by definition eliminates legacy entry point names on such pages.) _____________________________________________________________________________ objection Enhancement Request Number 296 drepper@redhat.com Bug in XSHd3 (rdvk# 432) {ud-60} Tue, 2 May 2000 04:22:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: socklen_t was not intended for this. _____________________________________________________________________________ Page: 484 Line: 15509 Section: gethostname() Problem: The type for the fourth parameter of inet_ntop is defined as socklen_t. This is contrary to the definition in RFC2553 and contrary to the intention of the usage of this type when it was introduced. socklen_t is supposed to be used for presentation of the length of addresses. The most prominent place where this is needed is for the third argument of accept(). The use in gethostname() is to describe the size of the output buffer, which are character array. This has nothing to do with the original intention of socklen_t. Action: Change the type of the second parameter back to the traditional size_t. This is also necessary in the appropriate man page in XBD. _____________________________________________________________________________ Objection Enhancement Request Number 297 donnte@microsoft.com Bug in XSHd3 (rdvk# 521) [DT-XSH-89] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 15615 The getlogin function shall return a pointer to a string containing the user name associated by the login activity with the controlling terminal of the current process. Delete the rest of the sentence ("which is the login name ..."). 5621 control --> controlling _____________________________________________________________________________ Page: 489 Line: 15615 Section: getlogin Problem: EMB The text at 15615 and 15621 seems unnecessarily different in describing two substantially identical functions. Only getlogin_r mentions the controlling terminal (not "control terminal"). Action: Make the two as parallel as possible (or if they really are different emphasize the difference more). If "control terminal" is retained, make "controlling terminal". _____________________________________________________________________________ objection Enhancement Request Number 298 drepper@redhat.com Bug in XSHd3 (rdvk# 431) {ud-59} Tue, 2 May 2000 04:22:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See 296 _____________________________________________________________________________ Page: 496 Line: 15876-15878 Section: getnameinfo() Problem: The type for the fourth parameter of inet_ntop is defined as socklen_t. This is contrary to the definition in RFC2553 and contrary to the intention of the usage of this type when it was introduced. socklen_t is supposed to be used for presentation of the length of addresses. The most prominent place where this is needed is for the third argument of accept(). The use in getnameinfo() is to describe the size of the output buffers `node` and `service`, which are character array. This has nothing to do with the original intention of socklen_t. Action: Change the type of the fourth and sixth parameter back to the traditional size_t. This is also necessary in the appropriate man page in XBD. _____________________________________________________________________________ Comment Enhancement Request Number 299 donnte@microsoft.com Bug in XSHd3 (rdvk# 522) [DT-XSH-90] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: these are normative requirements, which cannot be in definitions. They belong here. _____________________________________________________________________________ Page: 513 Line: 16408 Section: getpriority Problem: The text about the range of a nice value belongs in XBD, 2169. Given that, this paragraph can be simplified. Action: Add "The range of nice values is [0,{NZER0}*2-1], although more restrictive limits may be enforced." to XBD line 2169. Delete the first two sentences at 16408, as that information is now covered in the definiton of nice value. _____________________________________________________________________________ Objection Enhancement Request Number 300 donnte@microsoft.com Bug in XSHd3 (rdvk# 523) [DT-XSH-91] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change nam --> name. Make no other changes _____________________________________________________________________________ Page: 520 Line: 16518 Section: getpwnam Problem: I'm confused. There are a lot of references within this paragraph that are unclear, and although after several rereadings I finally "get" what they're after, it should be clearer. Also, is "name" at 16520 the same as "nam" at 16511? Action: At 16511 "nam" -> "name". Remove paragraph at 16518 (so that paragraph at 16525 immediately follows that at 16517, to keep topics together.) Put new paragraph after 16526: The _getpwnam_r_() function shall search for an entry corresponding to _name_ in the user data base. If it is found, the content of _pwd_ shall be replaced with the corresponding information. If additional storage (e.g., for strings) is needed to complete updating _pwd_, that storage shall be taken from _buffer_, up to _bufsize_ bytes worth. If an entry corresponding to _name_ is found, the value of _pwd_ shall be returned in *_result_; otherwise NULL shall be returned in *_result_. The maximum size needed for _buffer_ may be determined with the {_SC_GETPW_R_SIZE_MAX} _sysconf_() parameter. _____________________________________________________________________________ Objection Enhancement Request Number 301 donnte@microsoft.com Bug in XSHd3 (rdvk# 524) [DT-XSH-92] 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 with problem statement/suggested action _____________________________________________________________________________ Page: 520 Line: 16521 Section: getpwnam Problem: The size is in bytes, not characters. Action: "characters" -> "bytes". (Fixed implicitly in change above.) _____________________________________________________________________________ Objection Enhancement Request Number 302 donnte@microsoft.com Bug in XSHd3 (rdvk# 525) [DT-XSH-93] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: see 300 _____________________________________________________________________________ Page: 523 Line: 16623 Section: getpwuid Problem: Same issues as getpwnam(). Action: As for getpwnam. _____________________________________________________________________________ Objection Enhancement Request Number 303 donnte@microsoft.com Bug in XSHd3 (rdvk# 526) [DT-XSH-94] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: new text: Similarly, because the equal sign separates a token from its value, undefined behavior will result if the application passes a token that contains an equal sign. _____________________________________________________________________________ Page: 542 Line: 17173 Section: getsubopt Problem: "the application shall" implies new work that I don't believe was intended. Action: just "a token shall not contain an equal sign". _____________________________________________________________________________ Comment Enhancement Request Number 304 donnte@microsoft.com Bug in XSHd3 (rdvk# 527) [DT-XSH-95] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: ISO C 99 _____________________________________________________________________________ Page: 543 Line: 17212 Section: getsubopt Problem: This is not legal C (at least c89) because providing subscript elements for array initializers is not supported. (It is a legal gcc extension, apparently.) Action: Rewrite in standard-conforming C. (See also 17216.) _____________________________________________________________________________ Objection Enhancement Request Number 305 donnte@microsoft.com Bug in XSHd3 (rdvk# 528) [DT-XSH-96] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_306 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 543 Line: 17216 Section: getsubopt Problem: There should be a terminating null entry. Action: Add a null entry. _____________________________________________________________________________ comment Enhancement Request Number 306 drepper@redhat.com Bug in XSHd3 (rdvk# 412) {ud-52} Sun, 30 Apr 2000 10:44:47 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 543 Line: 17217 Section: getsubopt() Problem: The example (which I provided) contains a little bug. The array mount_opts is not terminated with a NULL pointer. Action: Add at the end of line 17216 a comma and as line 17217: NULL _____________________________________________________________________________ objection Enhancement Request Number 307 Sandra O Bug in XSHd3 (rdvk# 377) [compaq-smo-007] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 550 Line: 17435-17436 Section: getwchar Problem: Application Usage advice unclear. Action: Change Application Usage lines from "If the wint_t value returned by getwchar() is stored into a variable of type wchar_t and then compared against the wint_t macro WEOF, the comparison need never succeed." to "If the wint_t value returned by getwchar() is stored into a variable of type wchar_t and then compared against the wint_t macro WEOF, the result may be incorrect. Only the wint_t type is guaranteed to be able to represent any wide character and WEOF." This clearly explains that the comparison may not work because there is no guarantee that there be a unique value in wchar_t's domain to represent WEOF. _____________________________________________________________________________ comment Enhancement Request Number 308 drepper@redhat.com Bug in XSHd3 (rdvk# 2) {ud-10} Sun, 26 Mar 2000 00:45:57 GMT _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add to rationale: Since the user cannot specifyy the length of the buffer passed to getwd(), use of this function is discouraged. The length of a path name described in {PATH_MAX} is file system dependent and may vary from one mount point to another, or might even be unlimited. It is possible to overflow this buffer in such a way as to cause applications to fail, or possible system security violations. It is recommended that the getcwd() function should be used to determine the current working directory. For gets(), add this in APP USAGE: Since the user cannot specify the length of the buffer passed to gets(), use of this function is discouraged. The length of the string read is unlimited. It is possible to overflow this buffer in such a way as to cause applications to fail, or possible system security violations. It is recommended that the fgets() function should be used to read input lines. Remove the example section for gets(). _____________________________________________________________________________ Page: 551 Line: 17446 Section: getwd() Problem: Using this function is not discouraged enough. The application usage section should stress the security problems. Action: Replace the paragraph in lines 17466-17467 with: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since the user cannot specify the length of the buffer passed to the function this function is very dangerous. The length of a pat name described in {PATH_MAX} is filesystem dependent and may vary from one mount point to the other or might even be unlimited. Therefore, and for the sake of portability, the getcwd() function should be used to determine the current working directory. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _____________________________________________________________________________ Objection Enhancement Request Number 309 donnte@microsoft.com Bug in XSHd3 (rdvk# 529) [DT-XSH-97] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: will align with time in seconds since Epoch _____________________________________________________________________________ Page: 556 Line: 17656 Section: gmtime Problem: gmtime and gmtime_r have different descriptions unnecessarily. (One references "calendar time" the other "seconds since the Epoch".) Action: Choose one (I prefer gmtime's phrasing) or justify a difference. _____________________________________________________________________________ Objection Enhancement Request Number 310 donnte@microsoft.com Bug in XSHd3 (rdvk# 530) [DT-XSH-98] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Pseudo-terminal is defined in XBD. These interfaces are heavily used, and provide the only mechanism for doing these things. _____________________________________________________________________________ Page: 558 Line: 17706 Section: grantpt Problem: PTYs are not defined even as an XSI extension in this document (or it's well buried). Action: Drop this leftover (or define PTYs, which isn't a bad idea, but may be out of scope.) Also delete ptsname() and unlockpt(). _____________________________________________________________________________ Objection Enhancement Request Number 311 donnte@microsoft.com Bug in XSHd3 (rdvk# 531) [DT-XSH-99] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: non-responsive. To be considered this request would need to have contained more detailed suggestions (that align with historic practice!) _____________________________________________________________________________ Page: 558 Line: 17716 Section: grantpt Problem: Yetch... what an ugly constraint. (If interface is retained.) Action: Fix the problem or drop the interface (it should be fixable!). _____________________________________________________________________________ objection Enhancement Request Number 312 al.simons@compaq.com Bug in XSHd3 (rdvk# 428) {compaq-aks-026} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 563 Line: 17889-17890 Section: htonl Problem: Unclear and potentially misleading wording: "On some implementations, these functions are defined as macros that expand to the value of their argument." I believe that the phrase "that expand to the value of their argument" is unnecessary and misleading. It can be read to mean that htonl(0x12345678) expands to 0x12345678 on all systems, which is of course not true on little endian machines. The operation that must occur is defined in the RETURN VALUE section, so the description does not have to say anything more than, "On some implementations, these functions are defined as macros." Action: Change the sentence to read, "On some implementations, these functions are defined as macros." _____________________________________________________________________________ objection Enhancement Request Number 313 al.simons@compaq.com Bug in XSHd3 (rdvk# 429) {compaq-aks-027} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use the standard phrasing, "shall be defined as described in ..." _____________________________________________________________________________ Page: 563 Line: 17891 Section: htonl Problem: Confusing, incorrect and unnecessary comment about header file inclusion. The description states that the types are made available by inclusion of the header. In fact, that is not what XBD says. For the purposes of this XSH function, these types are supplied by inclusion of the header, which according to XBD must define these types "AS IF was included". Most implementations will, indeed, include into . However, the XBD standard does not require that. Therefore the htonl() description cannot require it. Action: (Preferred) Remove the sentence. (Alternative) Reword the sentence to say, "...by the inclusion of " _____________________________________________________________________________ objection Enhancement Request Number 314 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 149) [tog-c99-xsh 125] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 565 Line: 17925 Section: hypot Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Add after line 17925: float hypotf(float x, float y); long double hypotl(long double x, long double y); [Ed note: Add to CH The hypotf() and hypotl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 315 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 150) [tog-c99-xsh 126] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The hypot( ) function ..." To "The hypot(), hypotf() and hypotl() functions ..." Same change on line 17939. _____________________________________________________________________________ Page: 565 Line: 17927 Section: hypot Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Change "The hypot( ) function ..." To "The hypot family of functions ..." Same change on line 17939. _____________________________________________________________________________ objection Enhancement Request Number 316 aj@suse.de Bug in XSHd3 (rdvk# 408) {AJ1} Fri, 28 Apr 2000 19:41:13 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: ogtgbase : vwg/071/061994 resolved to align the man page to the header. _____________________________________________________________________________ Page: 567 Line: 17969 Section: iconv Problem: Since the iconv function doesn't change the values in the array pointed to by inbuf, we should mark the array with "const". Action: Change parameter inbuf from "char **inbuf" to "const char **inbuf". Besides changing XSH, the header iconv.h in XBD has also to be changed accordingly (page 276, line 9097). _____________________________________________________________________________ Objection Enhancement Request Number 317 donnte@microsoft.com Bug in XSHd3 (rdvk# 532) [DT-XSH-100] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The app usage is useful and should be left. Rephrase 18098 as suggested. _____________________________________________________________________________ Page: 571 Line: 18118 Section: iconv_open Problem: "must assume that" is pretty ugly. Action: Remove this, and rephrase at 18098: A conversion descriptor remains valid until it is closed by iconv_close or an implicit close. _____________________________________________________________________________ comment Enhancement Request Number 318 prindle@voicenet.com Bug in XSHd3 (rdvk# 640) [prindle.xsh-10] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 573 Line: 18137 Section: if_freenameindex() Problem: This line talks about the "if_nameindex" argument. The argument is really named "ptr". "if_nameindex" is the name of a function and also a structure, but not an agrument. Action: Change "if_nameindex argument" to "ptr argument". ------------------------------------------------------------------------------- _____________________________________________________________________________________ objection Enhancement Request Number 319 al.simons@compaq.com Bug in XSHd3 (rdvk# 423) also if_nameindex also if_nametoindex {compaq-aks-028}Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________________ Page: 574 Line: 18161,18166,18168,18170,18171 Section: if_indextoname Problem: The if_indextoname, if_nameindex and if_nametoindex functions operate on network interfaces, but the NAME and DESCRIPTION sections talk about them as if they operate on functions. Most instances of the word "function" in these three descriptions should be replaced with the word "interface", or the words "network interface" at the editor's choice, along with appropriate article modification, e.g., "a function" -> "an interface". (My preference would be to use "network interface" in the NAME section, and "interface" in the DESCRIPTION.) Action: at page 574 section if_indextoname line 18161 change "a function" to "a network interface" line 18166 change "a function" to "an interface" line 18168 change "name of the function" to "name of the interface" line 18170 change "is a function index" to "is an interface index" line 18171 change "containing the function" to "containing the interface" at page 575 section if_nameindex line 18190 change "all function" to "all network interface" line 18196 change "function. The" to "interface. The" line 18201 change "local functions." to "local interfaces." at page 576 section if_nametoindex line 18220 change "a function" to "a network interface" line 18225 change "the function" to "the interface" line 18227 change "a function" to "an interface" _____________________________________________________________________________ comment Enhancement Request Number 320 al.simons@compaq.com Bug in XSHd3 (rdvk# 424) also if_nametoindex Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add: "[ENXIO] the interface does not exist." where suggested. Also add " and set errno to indicate the error" on line 18172 _____________________________________________________________________________ Page: 574 Line: 18175 Section: if_indextoname {compaq-aks-029} Problem: What is the relationship between this spec and IETF RFC 2553, which first defined these functions? The RFC documents the error return ENXIO when the identified interface does not exist. The current wording of XSHd3 defines that the functions return a null pointer, but, by not mentioning it, indicates that errno is left unchanged. Is it viewed that aligning the two specifications is good or needed, or does this specification supercede RFC 2553? Action: If this spec should be changed to be compatible with IETF RFC 2553, then at page 574 line 18175 AND page 576 line 18230: add error [ENXIO] interface does not exist. _____________________________________________________________________________ comment Enhancement Request Number 321 drepper@redhat.com Bug in XSHd3 (rdvk# 414) {ud-56} Sun, 30 Apr 2000 10:44:47 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: also remove the errors on 18142. Also remove EFAULT errors in accept, connect getpeename getsockname getsockopt if_freenameindex if_indextoname if_nametoindex recv recvfrom recvmsg send sendmsg sendto setsockopt . _____________________________________________________________________________ Page: 576 Line: 18230 Section: if_nametoindex() Problem: The draft currently says that the if_nametoindex() implementation *shall* fail if the buffer pointer to by the parameter cannot be accessed. This is almost impossible to implement without major effort in normal runtime environments and against common practice in the standard. Action: Either remove the error entirely (which is what I prefer) or make the error option and replace the sentence in line 18229 with: The if_nametoindex() function may fail if: _____________________________________________________________________________ objection Enhancement Request Number 322 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 120) [tog-c99-xsh 96] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 577 Line: 18248 Section: ilogb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Add after line 18248: int ilogbf(float x); int ilogbl(long double x); [Ed note: Add to CH The ilogbf() and ilogbl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 323 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 121) [tog-c99-xsh 97] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The ilogb( ) function ..." To "The ilogb(), ilogbf() and ilogbl() functions ..." _____________________________________________________________________________ Page: 577 Line: 18251 Section: ilogb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Change "The ilogb( ) function ..." To "The ilogb family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 324 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 122) [tog-c99-xsh 98] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 577 Line: 18254 Section: ilogb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Delete line 18254 (it is covered in tog-c99-xsh 99). _____________________________________________________________________________ objection Enhancement Request Number 325 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 123) [tog-c99-xsh 99] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace lines 18256-18258 with: Upon successful completion, the ilogb(), ilogbf() and ilogbl() functions shall return the exponent part of x as a signed int value. If x is zero the ilogb(), ilogbf() and ilogbl() functions shall return the value FP_ILOGB0; if x is infinite they shall return the value INT_MAX; if x is a NaN they shall return the value FP_ILOGBNAN; otherwise, they shall be equivalent to calling the corresponding logb() function and casting the returned value to type int. _____________________________________________________________________________ Page: 577 Line: 18256-18258 Section: ilogb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Replace lines 18256-18258 with: Upon successful completion, the ilogb family of functions shall return the exponent part of x as a signed int value. If x is zero the ilogb family of functions shall return the value FP_ILOGB0; if x is infinite they shall return the value INT_MAX; if x is a NaN they shall return the value FP_ILOGBNAN; otherwise, they shall be equivalent to calling the corresponding logb() function and casting the returned value to type int. _____________________________________________________________________________ objection Enhancement Request Number 326 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 124) [tog-c99-xsh 100] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace line 18260 with the following text: The ilogb(), ilogbf() and ilogbl() functions may fail if: [ERANGE] The value of x is 0. _____________________________________________________________________________ Page: 577 Line: 18260 Section: ilob Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Replace line 18260 with the following text: The ilogb family of functions may fail if: [ERANGE] The value of x is 0. _____________________________________________________________________________ Objection Enhancement Request Number 327 donnte@microsoft.com Bug in XSHd3 (rdvk# 533) [DT-XSH-101] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add "which is the value of FLT_RADIX defined in the float.h header". Update see also as suggested. _____________________________________________________________________________ Page: 577 Line: 18270 Section: ilogb Problem: I'd still rather it was deleted as pretty useless (See ERN 296). However, at least add SEE ALSO to scalb() Also, to make effective use of this call, the programmer needs to know "r", which is FLT_RADIX in float.h Action: Add at 18253: The value of r is FLT_RADIX found in float.h Add scalb(), float.h to SEE ALSO section. _____________________________________________________________________________ objection Enhancement Request Number 328 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 61) [tog-c99-xsh 37] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 577 Line: 18274 Section: imaxdiv Problem: Change required for alignment with C99 (ref C99 section 7.8.2.2). Action: Add the following entry after line 18274: NAME imaxdiv - return quotient and remainder SYNOPSIS #include imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); 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 imaxdiv() function shall compute numer / denom and numer % denom in a single operation. RETURN VALUE The imaxdiv() function shall return a structure of type imaxdiv_t comprising both the quotient and the remainder. The structure shall contain (in either order) the members quot (the quotient) and rem (the remainder), each of which has type intmax_t. If either part of the result cannot be represented, the behavior is undefined. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO imaxabs(), 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 329 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 60) [tog-c99-xsh 36] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 577 Line: 18274 Section: imaxabs Problem: Change required for alignment with C99 (ref C99 section 7.8.2.1). Action: Add the following entry after line 18274: NAME imaxabs - return absolute value SYNOPSIS #include intmax_t imaxabs(intmax_t j); 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 imaxabs() function shall compute the absolute value of an integer j. If the result cannot be represented, the behavior is undefined. RETURN VALUE The imaxabs() function shall return the absolute value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The absolute value of the most negative number cannot be represented in two's complement. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO imaxdiv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ comment Enhancement Request Number 330 prindle@voicenet.com Bug in XSHd3 (rdvk# 641) [prindle.xsh-11] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A revnote has been added to the draft calling for assistance with the shading. _____________________________________________________________________________ Page: 586 Line: 18415 Section: inet_ntop() Problem: These functions are marked as part of the IP6 option. The equivalent IPv4 functions (inet_addr(), inet_ntoa()) are marked LEGACY and should not be used in new applications. This creates a problem for applications targeted for implementations not supporting the IP6 option. In a pinch, getipnodebyname() can substitute for inet_addr(), but getipnodebyaddr() would not appear to provide the functionality of inet_ntoa(). The legacy functions have not info in APPLICATION USAGE suggesting other alternatives. Action: Make these functions mandatory, and mark IPv6 specific functionality as part of the IP6 option, but have IPv4 functionality supported by all implementations (i.e. leave unshaded). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 331 drepper@redhat.com Bug in XSHd3 (rdvk# 430) {ud-58} Tue, 2 May 2000 04:22:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: see 296/298 _____________________________________________________________________________ Page: 586 Line: 18417 Section: inet_ntop() Problem: The type for the fourth parameter of inet_ntop is defined as socklen_t. This is contrary to the definition in RFC2553 and contrary to the intention of the usage of this type when it was introduced. socklen_t is supposed to be used for presentation of the length of addresses. The most prominent place where this is needed is for the third argument of accept(). The use in inet_ntop() is to describe the size of the destination buffer, which is a character array. It will contain the printable representation of the network address. This has nothing to do with the original intention of socklen_t. Action: Change the type of the third parameter back to the tradinitional size_t. This is also necessary in the man page in XBD. _____________________________________________________________________________ objection Enhancement Request Number 332 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 48) [tog-c99-xsh 24] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 609 Line: 19313 Section: isblank Problem: Change required for alignment with C99 (ref C99 section 7.4.1.3). Action: Add the following entry after line 19313: NAME isblank - test for a blank character SYNOPSIS #include int isblank(int c); 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 isblank( ) function shall test whether c is a character of class blank in the program's current locale; see the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale. In all cases c is a type int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. RETURN VALUE The isblank( ) function shall return non-zero if c is a blank character; otherwise, it shall return 0. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE To ensure applications portability, especially across natural languages, only this function and those listed in the SEE ALSO section should be used for character classification. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isalnum(), isalpha (), iscntrl(), isdigit (), isgraph(), islower(), isprint(), ispunct(), isspace(), isupper(), isxdigit (), setlocale ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 333 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 69) [tog-c99-xsh 45] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 612 Line: 19425 Section: isfinite Problem: Change required for alignment with C99 (ref C99 section 7.12.3.2). Action: Add the following entry after line 11588: NAME isfinite - test for finite value SYNOPSIS #include int isfinite(real-floating 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 isfinite() macro shall determine whether its argument has a finite value (zero, subnormal, or normal, and not infinite or NaN). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isfinite() macro shall return a nonzero value if and only if its argument has a finite value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isinf(), isnan(), isnormal(), signbit(), 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 334 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 70) [tog-c99-xsh 46] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: isinf Problem: Change required for alignment with C99 (ref C99 section 7.12.3.3). Action: Add the following entry after line 11588: NAME isinf - test for infinity SYNOPSIS #include int isinf(real-floating 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 isinf() macro shall determine whether its argument value is an infinity (positive or negative). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isinf() macro shall return a nonzero value if and only if its argument has an infinite value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isnan(), isnormal(), signbit(), 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 335 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 206) [tog-c99-xsh 180] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: isgreaterequal Problem: Change required for alignment with C99 (ref C99 section 7.12.14.2). Action: Add the following entry after line 19466: NAME isgreaterequal - test if x greater than or equal to y SYNOPSIS #include int isgreaterequal(real-floating x, real-floating y); 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 isgreaterequal() macro shall determine whether its first argument is greater than or equal to its second argument. The value of isgreaterequal(x, y) shall be equal to (x) >= (y); however, unlike (x) >= (y), isgreaterequal(x, y) shall not raise the invalid floating-point exception when x and y are unordered. RETURN VALUE The isgreaterequal() macro shall return the value of (x) >= (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isless(), islessequal(), islessgreater(), isunordered(), 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 336 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 208) [tog-c99-xsh 182] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: islessequal Problem: Change required for alignment with C99 (ref C99 section 7.12.14.4). Action: Add the following entry after line 19466: NAME islessequal - test if x less than or equal to y SYNOPSIS #include int islessequal(real-floating x, real-floating y); 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 islessequal() macro shall determine whether its first argument is less than or equal to its second argument. The value of islessequal(x, y) shall be equal to (x) <= (y); however, unlike (x) <= (y), islessequal(x, y) shall not raise the invalid floating-point exception when x and y are unordered. RETURN VALUE The islessequal() macro shall return the value of (x) <= (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessgreater(), isunordered(), 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 337 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 205) [tog-c99-xsh 179] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: isgreater Problem: Change required for alignment with C99 (ref C99 section 7.12.14.1). Action: Add the following entry after line 19466: NAME isgreater - test if x greater than y SYNOPSIS #include int isgreater(real-floating x, real-floating y); 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 isgreater() macro shall determine whether its first argument is greater than its second argument. The value of isgreater(x, y) shall be equal to (x) > (y); however, unlike (x) > (y), isgreater(x, y) shall not raise the invalid floating-point exception when x and y are unordered. RETURN VALUE The isgreater() macro shall return the value of (x) > (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreaterequal(), isless(), islessequal(), islessgreater(), isunordered(), 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 338 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 209) [tog-c99-xsh 183] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: islessgreater Problem: Change required for alignment with C99 (ref C99 section 7.12.14.5). Action: Add the following entry after line 19466: NAME islessgreater - test if x less than or greater than y SYNOPSIS #include int islessgreater(real-floating x, real-floating y); 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 islessgreater() macro shall determine whether its first argument is less than or greater than its second argument. The islessgreater(x, y) macro is similar to (x) < (y) || (x) > (y); however, islessgreater(x, y) shall not raise the invalid floating-point exception when x and y are unordered (nor shall it evaluate x and y twice). RETURN VALUE The islessgreater() macro shall return the value of (x) < (y) || (x) > (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessequal(), isunordered(), 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 339 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 207) [tog-c99-xsh 181] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 613 Line: 19466 Section: isless Problem: Change required for alignment with C99 (ref C99 section 7.12.14.3). Action: Add the following entry after line 19466: NAME isless - test if x less than y SYNOPSIS #include int isless(real-floating x, real-floating y); 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 isless() macro shall determine whether its first argument is less than its second argument. The value of isless(x, y) shall be equal to (x) < (y); however, unlike (x) < (y), isless(x, y) shall not raise the invalid floating-point exception when x and y are unordered. RETURN VALUE The isless() macro shall return the value of (x) < (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), islessequal(), islessgreater(), isunordered(), 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 340 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 71) [tog-c99-xsh 47] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 615 Line: 19527-19556 Section: isnan Problem: Change required for alignment with C99 (ref C99 section 7.12.3.4). Action: Change lines 19527-19556 to the following: NAME isnan - test for a NaN SYNOPSIS #include int isnan(real-floating 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 isnan() macro shall determine whether its argument value is a NaN. First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isnan() macro shall return a nonzero value if and only if its argument has a NaN value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnormal(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 3. Issue 4 The words not supporting NaN are added to the APPLICATION USAGE section. Issue 5 The DESCRIPTION is updated to indicate the return value when NaN is not supported. This text was previously published in the APPLICATION USAGE section. Issue 6. Issue 6 Entry re-written for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 341 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 72) [tog-c99-xsh 48] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 616 Line: 19556 Section: isnormal Problem: Change required for alignment with C99 (ref C99 section 7.12.3.5). Action: Add the following entry after line 19556: NAME isnormal - test for a normal value SYNOPSIS #include int isnormal(real-floating 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 isnormal() macro shall determine whether its argument value is normal (neither zero, subnormal, infinite, nor NaN). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isnormal() macro shall return a nonzero value if and only if its argument has a normal value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnan(), signbit(), 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 342 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 210) [tog-c99-xsh 184] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 619 Line: 19678 Section: isunordered Problem: Change required for alignment with C99 (ref C99 section 7.12.14.6). Action: Add the following entry after line 19678: NAME isunordered - test if arguments are unordered SYNOPSIS #include int isunordered(real-floating x, real-floating y); 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 isunordered() macro shall determine whether its arguments are unordered. RETURN VALUE The isunordered() macro shall return 1 if its arguments are unordered and 0 otherwise. If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships less, greater, and equal is true. Relational operators may raise the invalid floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the invalid floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessequal(), islessgreater(), 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 343 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 360) [tog-c99-xsh 334] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 624 Line: 19804 Section: iswblank Problem: Change required for alignment with C99 (ref C99 section 7.25.2.1.3). Action: Add the following entry after line 19804: NAME iswblank - test for a blank wide-character code SYNOPSIS #include int iswblank(wint_t wc); 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 The iswblank() function shall test whether wc is a wide-character code representing a character of class blank in the programs current locale; see the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale. In all cases wc is a wint_t, the value of which the application shall ensure is a wide-character code corresponding to a valid character in the current locale, or equal to the value of the macro WEOF. If the argument has any other value, the behavior is undefined. RETURN CODE The iswblank() function shall return non-zero if wc is a blank wide-character code; otherwise, it shall return 0. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE To ensure applications portability, especially across natural languages, only this function and those listed in the SEE ALSO section should be used for classification of wide-character codes. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO iswalnum(), iswalpha(), iswcntrl(), iswctype(), iswdigit (), iswgraph(), iswlower(), iswprint(), iswpunct(), iswspace(), iswupper(), iswxdigit (), setlocale ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , , , the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ Objection Enhancement Request Number 344 jeffcope@microsoft.com bug in XSHd3 (rdvk# 676) [Copeland-xsh-1] Mon, 1 May 2000 16:36:35 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "implementation-dependent" on line 19862 to "unspecified". _____________________________________________________________________________ Page: 627 Line: 19860 Section: Problem: The statement "If the value of charclass is invalid ... the result is implementation-dependent." requires a conformance statement, which I don't think is what we want to do. (The C standard is silent on invalid values of charclass, by the way, despite lines 19854-56, marked CX.) Action: Change "implementation-dependent" on line 19862 to "undefined". _____________________________________________________________________________ Objection Enhancement Request Number 345 jeffcope@microsoft.com bug in XSHd3 (rdvk# 677) [Copeland-xsh-2] Mon, 1 May 2000 16:36:35 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The iswctype() function shall return non-zero (true) if and only if wc has the property described by charclass. If charclass is 0, iswctype() shall return 0. Shade the last sentence of this CX. _____________________________________________________________________________ Page: 627 Line: 19864 Section: Problem: What does the return value statement for iswctype() mean? "The iswctype() function shall return 0 for false and non-zero for true." 0 for false what? Also, because wctype() returns 0 for an invalid class, it's probably a reasonable expectation for a call of iswctype(x, 0) (e.g., iswctype(x,wctype("kanji")) in a non-Japanese locale) to return 0. Change line 19864 from "The iswctype() function shall return 0 for false and non-zero for true." to "The iswctype() function shall return non-zero if and only if wc has the property described by charclass. If charclass is 0, iswctype() shall return 0." (The first sentence of that replacement aligns better with C99.) _____________________________________________________________________________ objection Enhancement Request Number 346 Sandra O Bug in XSHd3 (rdvk# 379) [compaq-smo-009] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 627 Line: 19873-19877 Section: iswctype Problem: Inconsistent names for program variable. Action: Change "valid-class" on line 19873 to "valid_class" to match the references on lines 19875 and 19877. _____________________________________________________________________________ objection Enhancement Request Number 347 Sandra O Bug in XSHd3 (rdvk# 378) [compaq-smo-008] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept change and use "vowel" _____________________________________________________________________________ Page: 627 Line: 19875 Section: iswctype Problem: Unrealistic example. Action: Change character class from "upper" to something else that is not a required class (examples: "national_character" or "vowel"). Since "upper" is a required class, it is unrealistic to use it as the parameter to wctype(), and then for wctype() to return false for it. _____________________________________________________________________________ objection Enhancement Request Number 348 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 361) [tog-c99-xsh 335] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 627 Line: 19884 Section: iswctype Problem: Change required for alignment with C99 (ref C99 section 7.25.2.2.1). Action: Add after line 19884: iswblank(wc) iswctype( wc, wctype("blank")) _____________________________________________________________________________ objection Enhancement Request Number 349 ajosey@opengroup.org Bug in XSHd3 (rdvk# 364) {austin-review-178} Wed, 19 Apr 2000 14:36:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 627 Line: 19894-19896 Section: iswctype Problem: Change [tog-c99-xsh 335] means that the lines containing Note: The call: iswctype( wc, wctype("blank")) does not have an equivalent isw*()function." should be deleted (this rdvk follows up on austin-review seq 178) Action: delete lines 19894-19896 _____________________________________________________________________________ objection Enhancement Request Number 350 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 289) [tog-c99-xsh 263] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 652 Line: 20520 Section: labs Problem: Change required for alignment with C99 (ref C99 section 7.20.6.1). Action: Add fter line 20520: long long int llabs(long long int i); [Ed note: Add to CH The llabs() function is added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 351 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 290) [tog-c99-xsh 264] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 652 Line: 20525 Section: labs Problem: Change required for alignment with C99 (ref C99 section 7.20.6.1). Action: Change "The labs() function ..." To "The labs() and llabs() functions ..." Same change on line 20528. _____________________________________________________________________________ Objection Enhancement Request Number 352 donnte@microsoft.com Bug in XSHd3 (rdvk# 534) [DT-XSH-102] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the synopsis is XSI shaded, which is defined to mean that the entire funtion is XSI _____________________________________________________________________________ Page: 653 Line: 20554 Section: lchown Problem: Again... symlinks need not have owners. Action: Since the claim is that XSI symlinks DO have owners (probably a bad idea, but it's your foot), at least add at 20554. Note: the concept of owners of symbolic links is specific to XSI; this call is not necessarily applicable if the XSI option is not supported. _____________________________________________________________________________ objection Enhancement Request Number 353 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 151) [tog-c99-xsh 127] 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, hypot( ) ..." To "Upon successful completion, the hypot(), hypotf() and hypotl() functions ..." _____________________________________________________________________________ Page: 656 Line: 17931 Section: hypot Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Change "Upon successful completion, hypot( ) ..." To "Upon successful completion, the hypot family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 354 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 125) [tog-c99-xsh 101] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 656 Line: 20620 Section: ldexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Add after line 20620: float ldexpf(float x, int exp); long double ldexpl(long double x, int exp); [Ed note: Add to CH The ldexpf() and ldexpl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 355 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 126) [tog-c99-xsh 102] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The ldexp( ) function ..." To "The ldexp(), ldexpf() and ldexpl() functions ..." Same change on lines 20636 and 20638. _____________________________________________________________________________ Page: 656 Line: 20625 Section: ldexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Change "The ldexp( ) function ..." To "The ldexp family of functions ..." Same change on lines 20636 and 20638. _____________________________________________________________________________ objection Enhancement Request Number 356 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 127) [tog-c99-xsh 103] 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, ldexp( ) shall return a double representing the value x multiplied by 2 raised to the power exp." To "Upon successful completion, the ldexp(), ldexpf() and ldexpl() functions shall return x multiplied by 2 raised to the power exp." _____________________________________________________________________________ Page: 656 Line: 20629-20630 Section: ldexp Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Change "Upon successful completion, ldexp( ) shall return a double representing the value x multiplied by 2 raised to the power exp." To "Upon successful completion, the ldexp family of functions shall return x multiplied by 2 raised to the power exp." _____________________________________________________________________________ objection Enhancement Request Number 357 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 291) [tog-c99-xsh 265] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 658 Line: 20667 Section: ldiv Problem: Change required for alignment with C99 (ref C99 section 7.20.6.2). Action: Add after line 20667: lldiv_t lldiv(long long int numer, long long int denom); [Ed note: Add to CH The lldiv() function is added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 358 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 292) [tog-c99-xsh 266] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 658 Line: 20672 Section: ldiv Problem: Change required for alignment with C99 (ref C99 section 7.20.6.2). Action: Change "The ldiv() function ..." To "The ldiv() and lldiv() functions ..." Same change on line 20677. _____________________________________________________________________________ objection Enhancement Request Number 359 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 166) [tog-c99-xsh 141] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The lgamma( ) function ..." To "The lgamma family of functions ..." Same change on lines 20719 and 20731. _____________________________________________________________________________ Page: 660 Line: 20713 Section: lgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "The lgamma( ) function ..." To "The lgamma(), lgammaf() and lgammal() functions ..." Same change on lines 20719 and 20731. _____________________________________________________________________________ objection Enhancement Request Number 360 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 165) [tog-c99-xsh 140] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 660 Line: 20719 Section: lgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Add after line 20719: float lgammaf(float x); long double lgammal(long double x); [Ed note: Add to CH The lgammaf() and lgammal() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 361 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 168) [tog-c99-xsh 143] 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, lgamma( ) ..." To "Upon successful completion, the lgamma(), lgammaf() and lgammal() functions ..." _____________________________________________________________________________ Page: 660 Line: 20722 Section: lgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "Upon successful completion, lgamma( ) ..." To "Upon successful completion, the lgamma family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 362 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 167) [tod-c99-xsh 142] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 660 Line: 20724-20725 Section: lgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "If x is a non-positive integer, either HUGE_VAL or NaN shall be returned and errno may be set to [EDOM]." To "If x is a non-positive integer, either HUGE_VAL or NaN shall be returned and errno may be set to [ERANGE]." [Ed note: Add to CH The RETURN VALUE and ERRORS sections are updated so that when x is a non-positive integer, errno may be set to [ERANGE], previously this was [EDOM]. This change is for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 363 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 169) [tog-c99-xsh 143a] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 660 Line: 20732-20733 Section: lgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "[EDOM] The value of x is a non-positive integer or NaN. [ERANGE] The value to be returned would have caused overflow or underflow." To "[EDOM] The value of x is NaN. [ERANGE] The value of x is a non-positive integer, or the value to be returned would have caused overflow or underflow." _____________________________________________________________________________ Editorial Enhancement Request Number 364 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 627) [DWC-38] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 668 Line: 20997 Section: lio_listio Problem: (missing option reference) This sentence is not complete. Action: Add "Asynchronous Input and Output option." to the end of P668, L20997. ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 365 al.simons@compaq.com Bug in XSHd3 (rdvk# 419) {compaq-aks-022} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_364 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 668 Line: 20997 Section: lio_listio Problem: The sentence is not completed. Action: Complete the sentence by adding the appropriate option name. _____________________________________________________________________________ objection Enhancement Request Number 366 Sandra O Bug in XSHd3 (rdvk# 380) [compaq-smo-010] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 671 Line: 21062 Section: localeconv Problem: Incorrect short description of function Action: Change "determine the program locale" to "return locale-specific information" for localeconv. The function most certainly does not determine the program locale. _____________________________________________________________________________ objection Enhancement Request Number 367 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 367) {drb-011} Tue, 25 Apr 2000 13:45:15 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: see email discussion. Does not improve the problem. _____________________________________________________________________________ Page: 671 Line: 21065 Section: localeconv 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. In the response to POSIX 1003.1 interpretation request #39, the POSIX interpretations committee concurred that the functions getenv_r(), localeconv_r(), and strerror_r() had been inadvertently omitted from the standard, and recommended that they be added to a future revision. XSH6D3 should be that future revision. I am going to submit 3 separate bugs to cover this interpretation, one containing each of three proposed new man pages, rather than submit one annoyingly large bug containing all three. (The preceding header text will appear in all 3 for reference.) Action: Add localeconv_r() to the localeconv() man page: This is a long and complicated man page. I have decided to "bend the rules" and forego proposing a new man page. This is because, while I have undertaken the effort of bringing POSIX interpretations to the XSH6 bug list, my principle interests in this particular interpretation were getenv_r() and strerror_r(). I am not a user of the locale functions, and I believe that resolving the "interesting issues" in this case would take longer than I can afford to dedicate to the job at this time. Trivially, one would add a prototype such as: int localeconv_r (struct lconv *locale); This would COPY the current locale description into the locale buffer rather than returning a pointer to a static buffer. However, the struct lconv members are char* pointers to strings. Where do those strings reside? If they are copied from the process lconv structure (if such a thing exists), they may be altered (or invalidated) by asynchronous locale changes made by other threads, and that would make localeconv_r pointless. Alternately, one could specify: int localeconv_r (struct lconv **locale, void *localebuf, size_t buflen); Such that localeconv_r created in localebuf both a struct lconv (a pointer to which would be returned in locale) AND copies of all the individual strings, to which the members of that structure would point. (Returning ERANGE if the allocated buffer is insufficient.) Which is desirable (or necessary) would depend on the storage of the process locale information (especially, are the individual string values to which the members point actually subject to dynamic modification?) I do not use, implement, or support locale functions. Therefore, I'm neither the most appropriate person to deal with these issues, nor can I justify spending my time to learn how to deal with them. If this means that XSH6 is lessened by the continued omission of this function, then that's unfortunate, but "so be it". _____________________________________________________________________________ objection Enhancement Request Number 368 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 64) [tog-c99-xsh 40] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: do not sort list. Do everything else (add new items at end). Remove XSI shading for all "int_curr_symbol" _____________________________________________________________________________ Page: 672 Line: 21131 Section: localeconv Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21131 [Note. This table needs sorting]: char int_p_cs_precedes Set to 1 or 0 if the int_currency_symbol respectively precedes or succeeds the value for a nonnegative internationally formatted monetary quantity. char int_n_cs_precedes Set to 1 or 0 if the int_currency_symbol respectively precedes or succeeds the value for a negative internationally formatted monetary quantity. char int_p_sep_by_space Set to a value indicating the separation of the int_currency_symbol, the sign string, and the value for a nonnegative internationally formatted monetary quantity. char int_n_sep_by_space Set to a value indicating the separation of the int_currency_symbol, the sign string, and the value for a negative internationally formatted monetary quantity. char int_p_sign_posn Set to a value indicating the positioning of the positive_sign for a nonnegative internationally formatted monetary quantity. char int_n_sign_posn Set to a value indicating the positioning of the negative_sign for a negative internationally formatted monetary quantity. _____________________________________________________________________________ objection Enhancement Request Number 369 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 65) [tog-c99-xsh 41] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 672 Line: 21137 Section: localeconv Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21137: The values of p_sep_by_space, n_sep_by_space, int_p_sep_by_space, and int_n_sep_by_space are interpreted according to the following: 0 No space separates the currency symbol and value. 1 If the currency symbol and sign string are adjacent, a space separates them from the value; otherwise, a space separates the currency symbol from the value. 2 If the currency symbol and sign string are adjacent, a space separates them; otherwise, a space separates the sign string from the value. [Ed note: Add to CH This page is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 370 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 66) [tog-c99-xsh 42] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 672 Line: 21138 Section: localeconv Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Change "The values of p_sign_posn and n_sign_posn are interpreted according to the following: To "The values of p_sign_posn, n_sign_posn, int_p_sign_posn, and int_n_sign_posn are interpreted according to the following:" _____________________________________________________________________________ objection Enhancement Request Number 371 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 67) [tog-c99-xsh 43] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 673 Line: 21182 Section: localeconv Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21182: int_p_cs_precedes 1 1 1 1 int_n_cs_precedes 1 1 1 1 int_p_sep_by_space 0 0 0 0 int_n_sep_by_space 0 0 0 0 int_p_sign_posn 1 1 1 1 int_n_sign_posn 1 4 4 2 _____________________________________________________________________________ Objection Enhancement Request Number 372 donnte@microsoft.com Bug in XSHd3 (rdvk# 535) [DT-XSH-103] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: make change suggested and also change "clock" to "timer" on 21202, 21214, 17650 [gmtime] 17660, _____________________________________________________________________________ Page: 675 Line: 21208 Section: localtime Problem: As for gmtime, the _r version is inconsistent. Action: Same as for gmtime. _____________________________________________________________________________ Comment Enhancement Request Number 373 donnte@microsoft.com Bug in XSHd3 (rdvk# 536) [DT-XSH-104] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: too much historic practice and different semantics _____________________________________________________________________________ Page: 678 Line: 21305 Section: lockf Problem: Can we make one of fcntl locking or lockf legacy (so one is clearly preferred for new work)? I'm inclined to make the legacy one be lockf(). Action: Make legacy. _____________________________________________________________________________ objection Enhancement Request Number 374 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 128) [tog-c99-xsh 104] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 681 Line: 21427 Section: log Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Add after line 21247: float logf(float x); long double logl(long double x); [Ed note: Add to CH The logf() and logl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 375 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 129) [tog-c99-xsh 105] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The log( ) function ..." To "The log(), logf() and logl() functions ..." Same change on lines 21442 and 21444. _____________________________________________________________________________ Page: 681 Line: 21432 Section: log Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Change "The log( ) function ..." To "The log family of functions ..." Same change on lines 21442 and 21444. _____________________________________________________________________________ objection Enhancement Request Number 376 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 130) [tog-c99-xsh 106] 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, log( ) ..." To "Upon successful completion, the log(), logf() and logl() functions ..." _____________________________________________________________________________ Page: 681 Line: 21437 Section: log Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Change "Upon successful completion, log( ) ..." To "Upon successful completion, the log family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 377 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 131) [tog-c99-xsh 107] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 683 Line: 21476 Section: log10 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Add after line 21476: float log10f(float x); long double log10l(long double x); [Ed note: Add to CH The log10f() and log10l() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 378 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 132) [tog-c99-xsh 108] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The log10( ) function ..." To "The log10(), log10f() and log10l() functions ..." Same change on lines 21491 and 21493. _____________________________________________________________________________ Page: 683 Line: 21481 Section: log10 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Change "The log10( ) function ..." To "The log10 family of functions ..." Same change on lines 21491 and 21493. _____________________________________________________________________________ objection Enhancement Request Number 379 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 133) [tog-c99-xsh 109] 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, log10( ) ..." To "Upon successful completion, the log10(), log10f() and log10l() functions ..." _____________________________________________________________________________ Page: 683 Line: 21486 Section: log10 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Change "Upon successful completion, log10( ) ..." To "Upon successful completion, the log10 family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 380 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 134) [tog-c99-xsh 110] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 685 Line: 21526 Section: log1p Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Add after line 21526: float log1pf(float x); long double log1pl(long double x); [Ed note: Add to CH the log1pf() and log1pl() functions are for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 381 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 135) [tog-c99-xsh 111] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The log1p( ) function ..." To "The log1p(), log1pf() and log1pl() functions ..." Same change on lines 21536 and 21538. _____________________________________________________________________________ Page: 685 Line: 21528 Section: log1p Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Change "The log1p( ) function ..." To "The log1p family of functions ..." Same change on lines 21536 and 21538. _____________________________________________________________________________ objection Enhancement Request Number 382 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 136) [tog-c99-xsh 112] 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, log1p( ) ..." To "Upon successful completion, the log1p(), log1pf() and log1pl() functions ..." _____________________________________________________________________________ Page: 685 Line: 21531 Section: log1p Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Change "Upon successful completion, log1p( ) ..." To "Upon successful completion, the log1p family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 383 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 137) [tog-c99-xsh 113] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 685 Line: 21557 Section: log2 Problem: Change required for alignment with C99 (ref C99 section 7.12.6.10). Action: Add the following entry after line 21557: NAME log2 - compute base-2 logarithm SYNOPSIS #include double log2(double x); float log2f(float x); long double log2l(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 log2 family of functions shall compute the base-2 logarithm 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 Upon successful completion, the log2 family of functions shall return the base-2 logarithm of x. If x is NaN, the log2 family of functions shall return NaN and may set errno to [EDOM]. If x is less than 0, the log2 family of functions shall return -HUGE_VAL or NaN and set errno to [EDOM]. If x is 0, the log2 family of functions shall return -HUGE_VAL and may set errno to [ERANGE]. ERRORS The log2 family of functions shall fail if: [EDOM] The value of x is less than 0. The log2 family of functions may fail if: [EDOM] The value of x is NaN. [ERANGE] The value of x is 0. No other errors shall occur. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO log(), 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 384 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 138) [tog-c99-xsh 114] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 686 Line: 21563 Section: logb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Add after line 21563: float logbf(float x); long double logbl(long double x); [Ed note: Add to CH The logbf() and logbl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 385 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 139) [tog-c99-xsh 115] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The logb( ) function ..." To "The logb(), logbf() and logbl() functions ..." Same change on lines 21574 and 21576. _____________________________________________________________________________ Page: 686 Line: 21565 Section: logb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Change "The logb( ) function ..." To "The logb family of functions ..." Same change on lines 21574 and 21576. _____________________________________________________________________________ Objection Enhancement Request Number 386 donnte@microsoft.com Bug in XSHd3 (rdvk# 537) [DT-XSH-105] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: see 327 _____________________________________________________________________________ Page: 686 Line: 21567 Section: logb Problem: I'd still rather it was deleted as pretty useless (See ERN 296). However, at least add SEE ALSO to scalb() Also, to make effective use of this call, the programmer needs to know "r", which is FLT_RADIX in float.h Action: Add at 21567: The value of r is FLT_RADIX found in float.h Add scalb(), float.h to SEE ALSO section. _____________________________________________________________________________ objection Enhancement Request Number 387 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 140) [tog-c99-xsh 116] 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, logb( ) ..." To "Upon successful completion, the logb(), logbf(), and logbl() functions ..." _____________________________________________________________________________ Page: 686 Line: 21569 Section: logb Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Change "Upon successful completion, logb( ) ..." To "Upon successful completion, the logb family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 388 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 212) [tog-c99-xsh 186] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 687 Line: 21602-21604 Section: longjmp Problem: Change required for alignment with C99 (ref C99 section 7.13.2.1). Action: Change "If there is no such invocation, or if the function containing the invocation of setjmp() has terminated execution in the interim, the behavior is undefined." To "If there is no such invocation, or if the function containing the invocation of setjmp()macro has terminated execution in the interim, or if the invocation of setjmp() was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 389 donnte@microsoft.com Bug in XSHd3 (rdvk# 538) [DT-XSH-106] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 687 Line: 21607 Section: longjmp Problem: As written, this implies a full checkpoint/restart: the state of the system must be restored (with some truly odd exceptions) to that current at the time of the setjmp(). I think longjmp() was intended. (The other setjmp/longjmp pages have similar problems; I *think* I caught all of them.) See page 1194 line 36382. That text is correct. Action: "setjmp was called" -> "longjmp was called". _____________________________________________________________________________ objection Enhancement Request Number 390 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 213) [tog-c99-xsh 187] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "All accessible objects have values as of the time setjmp( ) was called, except that the values of ..." To "All accessible objects have values as of the time longjmp( ) was called, and all other components of the abstract machine have state (for example, floating-point status flags and open files), except that the values of ..." _____________________________________________________________________________ Page: 687 Line: 21607 Section: longjmp Problem: Change required for alignment with C99 (ref C99 section 7.13.2.1). Action: Change "All accessible objects have values as of the time setjmp( ) was called, except that the values of ..." Change "All accessible objects have values as of the time setjmp( ) was called, and all other components of the abstract machine have state (for example, floating-point status flags and open files), except that the values of ..." _____________________________________________________________________________ objection Enhancement Request Number 391 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 185) [tog-c99-xsh 159] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 689 Line: 21662 Section: lround Problem: Change required for alignment with C99 (ref C99 section 7.12.9.7). Action: Add the following entry after line 21662: NAME lround - round to nearest integer value SYNOPSIS #include long int lround(double x); long int lroundf(float x); long int lroundl(long double x); long long int llround(double x); long long int llroundf(float x); long long int llroundl(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 lround() and llround() functions shall round their argument to the nearest integer value, rounding halfway cases away from zero, regardless of the current rounding direction. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, an error has occurred. RETURN VALUE The lround() and llround() functions shall return the rounded integer value. If the rounded value is outside the range of the return type, the numeric result is unspecified. If the magnitude of x is too large, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The lround() and llround() functions may fail if: [ERANGE] The magnitude of x is too large. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. 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 392 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 183) [tog-c99-xsh 157] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 689 Line: 21662 Section: lrint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.5). Action: Add the following entry after line 21662: NAME lrint - round to nearest integer value using current rounding direction SYNOPSIS #include long int lrint(double x); long int lrintf(float x); long int lrintl(long double x); long long int llrint(double x); long long int llrintf(float x); long long int llrintl(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 lrint() and llrint() functions shall round their argument to the nearest integer value, rounding according to the current rounding direction. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, an error has occurred. RETURN VALUE The lrint() and llrint() functions shall return the rounded integer value. If the rounded value is outside the range of the return type, the numeric result is unspecified. If the magnitude of x is too large, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The lrint() and llrint() functions may fail if: [ERANGE] The magnitude of x is too large. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. 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 393 donnte@microsoft.com Bug in XSHd3 (rdvk# 539) [DT-XSH-107] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: If the objector wishes to file an interpretation request against .1 to clarify this, we will follow the interp committee's advice. _____________________________________________________________________________ Page: 692 Line: 21756 Section: lseek Problem: "in the gap" is not defined. Yes, it's that way in .1-1990, but that doesn't necessarily make it right. As it stands, it's interpretation bait. Action: Change to: "In the region of the file not actually written". _____________________________________________________________________________ Comment Enhancement Request Number 394 donnte@microsoft.com Bug in XSHd3 (rdvk# 540) [DT-XSH-108] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: if an example can be found it will be included. However, no volunteer stepped forward, so it was not done. _____________________________________________________________________________ Page: 696 Line: 21919 Section: makecontext Problem: This function really needs an example. Action: Ask an expert for a useful example of the use of this function. _____________________________________________________________________________ Objection Enhancement Request Number 395 donnte@microsoft.com Bug in XSHd3 (rdvk# 541) [DT-XSH-109] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 698 Line: 21953 Section: malloc Problem: shallification. Action: "returned is either" -> "returned shall be either". _____________________________________________________________________________ objection Enhancement Request Number 396 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 355) [tog-c99-xsh 329] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 702 Line: 22039 Section: mbrlen Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.1). Action: Change "size_t mbrlen(const char * s, size_t n, mbstate_t * ps);" To "size_t mbrlen(const char * restrict s, size_t n, mbstate_t * restrict ps);" [Ed note: Add to CH The mbrlen() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 397 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 356) [tog-c99-xsh 330] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 704 Line: 22090 Section: mbrtowc Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.2). Action: Change "size_t mbrtowc(wchar_t * pwc, const char * s, size_t n, mbstate_t * ps);" Change "size_t mbrtowc(wchar_t * restrict pwc, const char * restrict s, size_t n, mbstate_t * restrict ps);" [Ed note: Add to CH The mbrtowc() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 398 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 358) [tog-c99-xsh 332] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 707 Line: 22185-22186 Section: mbsrtowcs Problem: Change required for alignment with C99 (ref C99 section 7.24.6.4.1). Action: Change "size_t mbsrtowcs(wchar_t * dst, const char ** src, size_t len, mbstate_t * ps);" To "size_t mbsrtowcs(wchar_t * restrict dst, const char ** restrict src, size_t len, mbstate_t * restrict ps);" [Ed note: Add to CH The mbsrtowcs() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 399 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 295) [tog-c99-xsh 269] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 709 Line: 22238 Section: mbstowcs Problem: Change required for alignment with C99 (ref C99 section 7.20.8.1). Action: Change "size_t mbstowcs(wchar_t * pwcs, const char * s, size_t n);" To "size_t mbstowcs(wchar_t * restrict pwcs, const char * restrict s, size_t n);" [Ed note: Add to CH The mbstowcs() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 400 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 293) [tog-c99-xsh 267] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 710 Line: 22280 Section: mbtowc Problem: Change required for alignment with C99 (ref C99 section 7.20.7.2). Action: Change "int mbtowc(wchar_t * pwc, const char * s, size_t n);" To "int mbtowc(wchar_t * restrict pwc, const char * restrict s, size_t n);" [Ed note: Add to CH The mbtowc() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 401 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 297) [tog-c99-xsh 271] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 715 Line: 22435 Section: memcpy Problem: Change required for alignment with C99 (ref C99 section 7.21.2.1). Action: Change "void *memcpy(void * s1, const void * s2, size_t n);" To "void *memcpy(void * restrict s1, const void * restrict s2, size_t n);" [Ed note: Add to CH The memcpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 402 donnte@microsoft.com Bug in XSHd3 (rdvk# 542) [DT-XSH-110] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 721 Line: 22638 Section: mkfifo Problem: shallification Action: "group ID is" -> "group ID shall be". _____________________________________________________________________________ objection Enhancement Request Number 403 prindle@voicenet.com Bug in XSHd3 (rdvk# 642) [prindle.xsh-12] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove all SHM shading (except the synopsis), 23133 change memory object --> shared memory object or typed memory object and other stuff. The markup draft has the edits _____________________________________________________________________________ Page: 737 Line: 23155 Section: mmap() Problem: This line contradicts what is above. It was never modified to allow typed memory objects. Action: Change the shaded "and shared memory objects" to ", shared memory objects, and typed memory objects", and change margin code to SHM|TYM. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 404 donnte@microsoft.com Bug in XSHd3 (rdvk# 543) [DT-XSH-111] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "The system shall always zero-fill any partial page at the end of an object. Further, the system shall never write out any modified portions of the last page of an object which are beyond its end. [MPR shadeon] References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal."[end MPR shade] _____________________________________________________________________________ Page: 739 Line: 23229 Section: mmap Problem: shallficiation Action: Replace paragraph with the following. (Note to editors... use this as an example style guide for finding more substitutions of normal active verbs for what were (and need to be) "shall" requirements; I'm just picking up those I happen to notice.) "The system shall always zero-fill any partial page at the end of an object. Further the system shall never write out any modified portions of the last page of an object which are beyond its end. References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal." _____________________________________________________________________________ objection Enhancement Request Number 405 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 141) [tog-c99-xsh 117] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 744 Line: 23438 Section: modf Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Add after line 23438: float modff(float value, float *iptr); long double modfl(long double value, long double *iptr); [Ed note: Add to CH The modff() and modfl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 406 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 142) [tog-c99-xsh 118] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The modf( ) function ..." To "The modf(), modff() and modfl() functions ..." Same change on line 23454. _____________________________________________________________________________ Page: 744 Line: 23443 Section: modf Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Change "The modf( ) function ..." To "The modf family of functions ..." Same change on line 23454. _____________________________________________________________________________ objection Enhancement Request Number 407 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 143) [tog-c99-xsh 119] 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, modf( ) ..." To "Upon successful completion, the modf(), modff() and modfl() functions ..." _____________________________________________________________________________ Page: 744 Line: 23449 Section: modf Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Change "Upon successful completion, modf( ) ..." To "Upon successful completion, the modf family of functions ..." _____________________________________________________________________________ Objection Enhancement Request Number 408 donnte@microsoft.com Bug in XSHd3 (rdvk# 544) [DT-XSH-112] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: shallify the mprotect words to match the mmap phrasing. _____________________________________________________________________________ Page: 746 Line: 23499 Section: mprotect Problem: (You know, occasionally it DOES pay to predict the future... in ERN #200, I recommended that the duplication of the text between here and line 23167 (or so) in mmap() should be eliminated, on the grounds that they would sooner or later get out of sync. Guess what...) The text here and at 23167 in mmap are now out of sync. Action: Delete this paragraph and replace with: The protections actually provided are discussed under mmap(). [A more precise citation would be nice, but without section numbers....] OR (and better, but I'm not prepared to do that writing right now) Add to General Concepts a section on mapped memory protection, and add references to it from both here and mmap. _____________________________________________________________________________ objection Enhancement Request Number 409 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 416) {drb-013} Mon, 1 May 2000 18:00:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 754 Line: 23746 Section: mq_open 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. POSIX 1003.1 Interpretations request #48 points out an omission in the general editing pass that merged 1003.1c into the 1003.1 base document. In the description of the O_EXCL flag behavior, the standard states, incorrectly, that "The check for the existence of the message queue and the creation of the message queue if it does not exist shall be atomic with respect to other processes executing mq_open() naming the same name with O_EXCL and O_CREAT set." Action: The wording should be: The check for the existence of the message queue and the creation of the message queue if it does not exist shall be atomic with respect to other threads executing mq_open() naming the same name with O_EXCL and O_CREAT set. [Ed note: Add to CH The DESCRIPTION of O_EXCL is updated for IEEE PASC Interpretation 1003.1c #48] _____________________________________________________________________________ objection Enhancement Request Number 410 prindle@voicenet.com Bug in XSHd3 (rdvk# 632) [prindle.xsh-2] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Record the problem/action in a reviewers note: XSHd3 ERN 410 states.... _____________________________________________________________________________ Page: 756 Line: 23805,23808-23811 Section: mq_receive() Problem: Yes indeed, return type should be ssize_t. This opinion is confirmed by Michael Gonzalez, technical editor for .1d. This problem also applies to: page 763 line 24027 section mq_timed_receive() Action: Delete this note and... Change the first "int" on lines 23805 and 24027 to "ssize_t". If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision (SSWG-RT will immediately recommend the fix as part of the interpretation, because as it stands the .1d standard is inconsistent with .1 mq_receive()). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 411 donnte@microsoft.com Bug in XSHd3 (rdvk# 545) [DT-XSH-113] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: too much historic practice. These interfaces co-exist, and one does not replace the other. Some systems only execute the historical interfaces _____________________________________________________________________________ Page: 768 Line: 24145 Section: msgctl() Problem: The older interfaces are now supplanted by POSIX interfaces. Action: Replace this paragraph with... This standard also defines a set of mq_* functions which should be used for new application development. (Also on 24213, 24318, 24424) _____________________________________________________________________________ Objection Enhancement Request Number 412 donnte@microsoft.com Bug in XSHd3 (rdvk# 546) [DT-XSH-114] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move 24489 up to 24473 _____________________________________________________________________________ Page: 778 Line: 24472 Section: msync Problem: This text and the text at 24489 should be collected together. Action: Move 24489 to 24473. (Or vice versa.) (Ed... consider cleaning up language so the two sentences read nicely when adjacent.) _____________________________________________________________________________ objection Enhancement Request Number 413 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 193) [tog-c99-xsh 167] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 784 Line: 24628 Section: nan Problem: Change required for alignment with C99 (ref C99 section 7.12.11.2). Action: Add the following entry after line 24628: NAME nan - return quiet NaN SYNOPSIS #include double nan(const char *tagp); float nanf(const char *tagp); long double nanl(const char *tagp); 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 call nan("n-char-sequence") shall be equivalent to strtod("NAN(n-char-sequence)", (char**) NULL); the call nan("") shall be equivalent to strtod("NAN()", (char**) NULL). If tagp does not point to an n-char sequence or an empty string, the call shall be equivalent to strtod("NAN", (char**) NULL). Calls to nanf() and nanl() are equivalent to the corresponding calls to strtof() and strtold(). RETURN VALUE The nan() functions shall return a quiet NaN, if available, with content indicated through tagp. If the implementation does not support quiet NaNs, the functions shall return zero. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO strtod(), strtof(), strtold(), 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 414 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 177) [tog-c99-xsh 151] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 786 Line: 24685 Section: nearbyint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.3). Action: Add the following entry after line 24685: NAME nearbyint - floating-point rounding functions SYNOPSIS #include double nearbyint(double x); float nearbyintf(float x); long double nearbyintl(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 nearbyint() functions shall round their argument to an integer value in floating-point format, using the current rounding direction and without raising the inexact floating-point exception. 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 nearbyint() functions shall return the rounded integer value. If x is 1Inf, the nearbyint() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The nearbyint() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. 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 415 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 194) [tog-c99-xsh 168] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 787 Line: 24690 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add after line 24690: float nextafterf(float x, float y); long double nextafterl(long double x, long double y); double nexttoward(double x, long double y); float nexttowardf(float x, long double y); long double nexttowardl(long double x, long double y); [Ed note: Add to CH The nextafterf(), nextafterl(), nexttoward(), nexttowardf() and nexttowardl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 416 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 195) [tog-c99-xsh 169] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 787 Line: 24692 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24692: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. _____________________________________________________________________________ objection Enhancement Request Number 417 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 196) [tog-c99-xsh 170] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The nextafter( ) function ..." To "The nextafter() , nextafterf(), and nextafterl() functions ..." _____________________________________________________________________________ Page: 787 Line: 24693 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "The nextafter( ) function ..." To "The nextafter family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 418 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 197) [tog-c99-xsh 171] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "representable floating-point number less than x." To "representable floating-point number less than x. The nextafter() , nextafterf(), and nextafterl() functions shall return y is x equals y." _____________________________________________________________________________ Page: 787 Line: 24695 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "representable floating-point number less than x." To "representable floating-point number less than x. The nextafter() functions shall return y is x equals y." _____________________________________________________________________________ objection Enhancement Request Number 419 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 198) [tog-c99-xsh 172] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the following text after line 24695: The nexttoward(), nexttowardf() and nexttowardl() functions are equivalent to the corresponding nextafter() functions except that the second parameter has type long double and the functions return y converted to the type of the function if x equals y. _____________________________________________________________________________ Page: 787 Line: 24695 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24695: The nexttoward() functions are equivalent to the nextafter() functions except that the second parameter has type long double and the functions return y converted to the type of the function if x equals y. _____________________________________________________________________________ objection Enhancement Request Number 420 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 199) [tog-c99-xsh 173] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 787 Line: 24699 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "The nextafter() function ..." To "The nextafter() and nexttoward() functions ..." The same change applies to lines 24705 and 24707. _____________________________________________________________________________ objection Enhancement Request Number 421 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 200) [tog-c99-xsh 174] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the following text after line 24700: The nextafter(), nextafterf(), and nextafterl() functions shall return y if x equals y. _____________________________________________________________________________ Page: 787 Line: 24700 Section: nextafter Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24700: The nextafter() functions shall return y if x equals y. _____________________________________________________________________________ objection Enhancement Request Number 422 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 415) {drb-012} Mon, 1 May 2000 18:00:38 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 798 Line: 25002 Section: open 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. POSIX 1003.1 Interpretations request #48 points out an omission in the general editing pass that merged 1003.1c into the 1003.1 base document. In the description of the O_EXCL flag behavior, the standard states, incorrectly, that "The check for the existence of the file and the creation of the file if it does not exist shall be atomic with respect to other processes executing open() naming the same file name in the same directory with O_EXCL and O_CREAT set." Action: The wording should be: The check for the existence of the file and the creation of the file if it does not exist shall be atomic with respect to other threads executing open() naming the same file name in the same directory with O_EXCL and O_CREAT set. [Ed note: Add CH The DESCRIPTION of O_EXCL is updated for IEEE PASC Interpretation 1003.1c #48] _____________________________________________________________________________ Objection Enhancement Request Number 423 donnte@microsoft.com Bug in XSHd3 (rdvk# 547) [DT-XSH-115] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept first action, reject (look for other instances of gratuitous change). see .1 1996 lines 236-245 (page 119-120). _____________________________________________________________________________ Page: 799 Line: 25010 Section: open Problem: The original .1 text read "shall" throughout the paragraphs 25010 and 25013, but now it reads "shall only" which doesn't make sense. (If this was trying to fix an interpretation... I don't think it did; why was the text changed to begin with?) Action: Restore original .1 text (look for other instances of gratuitous change). _____________________________________________________________________________ Objection Enhancement Request Number 424 donnte@microsoft.com Bug in XSHd3 (rdvk# 548) [DT-XSH-116] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "Implementations may" to "The standard permits EACCESS to be returned for conditions other than those explicitly listed." _____________________________________________________________________________ Page: 803 Line: 25177 Section: open Problem: This is making a normative requirement in rationale, except that the normative requirement already exists as a general exception. Action: For clarity, change "Implementations may" to "The standard permits EACCESS to be returned for conditions other than those explicitly listed. Users should keep that in mind.". (Or "Users are reminded that....".) _____________________________________________________________________________ objection Enhancement Request Number 425 al.simons@compaq.com Bug in XSHd3 (rdvk# 420) {compaq-aks-023} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change opendir to closedir on 25322 _____________________________________________________________________________ Page: 807 Line: 25322-25323 Section: opendir Problem: The rationale states, "The description of opendir() clarifies that if a file descriptor is used for the directory stream, it is mandatory that closedir() deallocate the file descriptor." Ummm.... No, it doesn't. The description makes no statement about file descriptors except for stating that the total of file opens and opendirs() can't exceed {OPEN_MAX} if DIR is implemented as a file descriptor. Action: Add at the end of line 25276, "If the type DIR is implemented using a file descriptor, closedir() must deallocate the file descriptor." _____________________________________________________________________________ editorial Enhancement Request Number 426 al.simons@compaq.com Bug in XSHd3 (rdvk# 421) {compaq-aks-024} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Move lines 25326-25327 to the readdir() section. Move lines 25431-25364 to the readdir rationale _____________________________________________________________________________ Page: 807 Line: 25326-25327 Section: opendir Problem: These lines seem out of place; they should be in the readdir() section. Action: Move lines 25326-25327 to the readdir() section. _____________________________________________________________________________ Objection Enhancement Request Number 427 donnte@microsoft.com Bug in XSHd3 (rdvk# 549) [DT-XSH-117] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_426 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 808 Line: 25361 Section: opendir Problem: This makes reference to a thread-safe version, but I see no such thing explicitly defined. Either this is it (and this paragraph should be deleted) or it's not present (and this paragraph should be replaced) or it's present and I don't see it (and this paragraph should specifically point to it by name). Action: One of the above. _____________________________________________________________________________ Objection Enhancement Request Number 428 donnte@microsoft.com Bug in XSHd3 (rdvk# 550) [DT-XSH-118] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 816 Line: 25526 Section: pclose Problem: Editorial problems: Action: pop() -> popen() on 25526 bad line break on 25526. Need paragraph break at 25531. (As in original .2-1992, P 1039, l11884) _____________________________________________________________________________ editorial Enhancement Request Number 429 al.simons@compaq.com Bug in XSHd3 (rdvk# 422) {compaq-aks-025} Mon, 01 May 2000 12:31:09 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_428 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 816 Line: 25526 Section: pclose Problem: Undefined term "pop()ed" is used instead of "popen()ed", e.g., "...and then reads from the pop(0ed stream." Also at page 827 line 25890 section popen Action: Replace term "pop()ed" with "popen()ed" at the above points. _____________________________________________________________________________ Objection Enhancement Request Number 430 donnte@microsoft.com Bug in XSHd3 (rdvk# 551) [DT-XSH-119] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 823 Line: 25735 Section: poll Problem: This paragraph is badly placed. Action: Change 25732 to add sockets to the list of supported file types and delete this. _____________________________________________________________________________ Objection Enhancement Request Number 431 donnte@microsoft.com Bug in XSHd3 (rdvk# 552) [DT-XSH-120] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 827 Line: 25890 Section: popen Problem: It's "popen", not "pop". Action: 2) pop() -> popen(). _____________________________________________________________________________ Comment Enhancement Request Number 432 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 628) [DWC-39] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 827 Line: 25892 Section: popen Problem: (popen: rationale) When popen()'s rationale talks about "rules for streams", it needs to be clear whether it is talking about stdio streams or STREAMS. Action: Change "the rules for streams must be observed." on P827, L25892 to "the rules for sharing file handles must be observed (see section 2.5.1 Interaction of File Descriptors and Standard I/O Streams).". ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 433 donnte@microsoft.com Bug in XSHd3 (rdvk# 553) [DT-XSH-121] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: we will use an appropriate font Make sure that fopen, fdopen, freopen, and popen all use the same convention throughout. _____________________________________________________________________________ Page: 827 Line: 25893 Section: popen Problem: Font misuse. The characters 'w' and 'r' appear in bold, italic, and constant width font on this page. Use constant width everywhere for text that will be typed literally into the computer. Action: Use CW. _____________________________________________________________________________ editorial Enhancement Request Number 434 prindle@voicenet.com Bug in XSHd3 (rdvk# 643) [prindle.xsh-13] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 829 Line: 25962 Section: posix_fadvise() Problem: The "if the Advisory Information option is supported." is redundant given that this page is under the ADV option already, as are the symbols in . Action: Delete the phrase "if...supported" ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 435 prindle@voicenet.com Bug in XSHd3 (rdvk# 633) [prindle.xsh-3] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add reviewers note with problem statement/action _____________________________________________________________________________ Page: 833 Line: 23038-26044 Section: posix_madvise() Problem: Yes indeed, the correct header should be . This opinion is confirmed by Michael Gonzalez, technical editor for .1d. Action: Delete this note and accept objection [prindle.xbd-6] (moves this function's prototype from to ). If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision (SSWG-RT will immediately recommend the fix as part of the interpretation, because as it stands the .1d standard is internally inconsistent). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 436 prindle@voicenet.com Bug in XSHd3 (rdvk# 644) [prindle.xsh-14] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 833 Line: 26070-26071 Section: posix_fadvise() Problem: The "if the Advisory Information ... supported." is redundant given that this page is under the ADV and MF|SHM options already, as should be the symbols in (see [prindle.xbd-7]). Action: Delete the phrase "if...supported" (through second "supported") ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 437 donnte@microsoft.com Bug in XSHd3 (rdvk# 554) [DT-XSH-122] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: just void -- => void * _____________________________________________________________________________ Page: 837 Line: 26155 Section: posix_memalign Problem: Type void has no size. I think you meant "void *". Action: "void" -> "void *". (And the fonts are a mess; both sizeof and void should be in the same font (CW)). _____________________________________________________________________________ comment Enhancement Request Number 438 drepper@redhat.com Bug in XSHd3 (rdvk# 395) {ud-35} Sat, 15 Apr 2000 06:07:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Need to add a reviewers note with the problem statement/action _____________________________________________________________________________ Page: 839 Line: 26238-26239 Section: posix_spawn() Problem: I don't know how much of the text was taken from the POSIX specs but there is something missing here. The list of the steps to take does not say when the change of the default signal behaviour takes place. I guess this is during step 2. Action: Change lines 26238 to 26239 to: 2. The signal mask, signal default actions, and the effective user group and group IDs for the child process shall be changed as specific in the attributes object referenced by attrp. Note the addition of "signal default actions". _____________________________________________________________________________ editorial Enhancement Request Number 439 prindle@voicenet.com Bug in XSHd3 (rdvk# 646) [prindle.xsh-16] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 839 Line: 26254,26259 Section: posix_spawn() Problem: No shading for optional text. Action: Delete (in both lines) "_POSIX_PRIORITY_SCHEDULING is defined, and". Shade both these paragraphs, and use margin code PS. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 440 prindle@voicenet.com Bug in XSHd3 (rdvk# 647) [prindle.xsh-17] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 840 Line: 26295 Section: posix_spawn() Problem: No shading for optional text. Action: Delete "If the threads option is supported, then". Shade this paragraph, and use margin code THR. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 441 prindle@voicenet.com Bug in XSHd3 (rdvk# 648) [prindle.xsh-18] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 841 Line: 26317,26323 Section: posix_spawn() Problem: No shading for optional text. Action: Delete (in both lines) "_POSIX_PRIORITY_SCHEDULING is defined, and". Shade both these paragraphs, and use margin code PS. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 442 prindle@voicenet.com Bug in XSHd3 (rdvk# 649) [prindle.xsh-19] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the reviewers note, the example will go into XRAT _____________________________________________________________________________ Page: 841 Line: 26338 Section: posix_spawn() Problem: Note to reviewers here. Action: Yes, the example is of an implementation, not usage. But let's not lose it! N.B.: There is actually a bug in the example related to [prindle.xsh-1] - that is, posix_spawnattr_setsigdefault() is misspelled posix_spawnattr_setdefault() in the prototype - C doesn't catch this error because prototypes are not enforced. Michael Gonzalez will fix in .1d, we need to fix in our copy of the example. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 443 prindle@voicenet.com Bug in XSHd3 (rdvk# 650) [prindle.xsh-20] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add "(Ada)" in 26420. Editor has other markups for the following para. _____________________________________________________________________________ Page: 843 Line: 26420 Section: posix_spawn() Problem: The Ada procedure name in the header should be italicized to match this doc's convention for naming Ada procedures. Action: Italicize POSIX_Process_Primitives.Start_Process. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 444 drepper@redhat.com Bug in XSHd3 (rdvk# 393) {ud-34} Sat, 15 Apr 2000 06:07:12 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 844 Line: 26483 Section: posix_spawn() Problem: A typo: [...] other kind of error that my be returned by an arbitrary [...] Should be `may' not `my'. Action: Replace in line 26483 my with may. _____________________________________________________________________________ editorial Enhancement Request Number 445 drepper@redhat.com Bug in XSHd3 (rdvk# 394) {ud-34} Sat, 15 Apr 2000 06:07:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_444 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 844 Line: 26483 Section: posix_spawn() Problem: A typo: [...] other kind of error that my be returned by an arbitrary [...] Should be `may' not `my'. Action: Replace in line 26483 my with may. _____________________________________________________________________________ editorial Enhancement Request Number 446 prindle@voicenet.com Bug in XSHd3 (rdvk# 631) [prindle.xsh-1] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 845 Line: 26507,26509 Section: posix_spawn() Problem: posix_spawnattr_getdefault() should be posix_spawnattr_getsigdefault(). posix_spawnattr_setdefault() should be posix_spawnattr_setsigdefault(). This editorial error was discovered during final pre-publication editing of 1003.1d. Note that the correct name is used throughout .1d, and only appears misspelled this way in the synopsis section and the header section of the example. It is spelled correctly elsewhere. During the merge into Austin D3 the misspelled version seems to have propogated everywhere! This problem also applies to: page 854 line 26782,26784 section posix_spawnattr_destroy() page 855 line 26791,26796,26798,26805,26807,26810,26813,26818 section posix_spawnattr_getdefault() page 858 line 26881,26883 section posix_spawnattr_getflags() page 859 line 26926,26928 section posix_spawnattr_getgroup() page 861 line 26975,26977 section posix_spawnattr_getschedparam() page 863 line 27023,27025 section posix_spawnattr_getschedpolicy() page 865 line 27071,27072 section posix_spawnattr_getsigmask() page 868 line 27088,27093,27097 section posix_spawnattr_setdefault() Action: Fix the spelling of these functions everywhere (I've attempted to locate all the occurrences, but Acrobat's find function is not all that reliable). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 447 prindle@voicenet.com Bug in XSHd3 (rdvk# 651) [prindle.xsh-21] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "close and open spawn file actions object" to "add close or open action to spawn file actions object". On page 849, line 26625, change "add to spawn file actions object" to "add dup2 action to spawn file actions object. On page 850, line 26667, change "open spawn file actions object" to "add open action to spawn file actions object". _____________________________________________________________________________ Page: 846 Line: 26517-26518 Section: posix_spawn_file_actions_addclose() Problem: I've said it once, and I'll say it again, there is no fundamental reason to separate posix_spawn_file_actions_adddup2() from these two. But if you insist, let's at least get the description right. Action: Change "close and open spawn file actions object" to "add close or open to spawn file actions object". On page 849, line 26625, change "add to spawn file actions object" to "add dup2 to spawn file actions object. On page 850, line 26667, change "open spawn file actions object" to "add open to spawn file actions object". Better yet, combine these two pages and use the unified description on this and the other reference pages. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 448 drepper@redhat.com Bug in XSHd3 (rdvk# 392) {ud-32} Sat, 15 Apr 2000 06:07:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a revnote with the problem/action in it _____________________________________________________________________________ Page: 846 Line: 26543-26547 Section: posix_spawn_file_actions_adddup2 Problem: This probably is again a case for the POSIX committee. If yes, it should be brought up there. The description of the posix_spawn_file_actions_addopen function does not say whether the function has to make a copy of the path parameter or whether it can store the pointer and assume the application does not destroy the copy of the string. Action: Ask somebody who was in the POSIX committee and clarify the description by adding The string pointed to by path can become invalid so the function has to make a copy. or the reverse. _____________________________________________________________________________ comment Enhancement Request Number 449 drepper@redhat.com Bug in XSHd3 (rdvk# 391) {ud-31} Sat, 15 Apr 2000 06:07:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note with the problem statement/action in it _____________________________________________________________________________ Page: 849 Line: 26641 Section: posix_spawn_file_actions_adddup2 Problem: This probably is a case for the POSIX committee. If yes, it should be brought up there. The description of the EBADF error currently says: The value specified by fildes is negative or greater than or equal to {OPEN_MAX}. This is most probably also true for newfildes. Action: Change The value specified by fildes to The value specified by fildes or newfildes _____________________________________________________________________________ editorial Enhancement Request Number 450 prindle@voicenet.com Bug in XSHd3 (rdvk# 652) Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 851 Line: 26694 Section: posix_spawn_file_actions_destroy() [prindle.xsh-22] Problem: An important semantic regarding posix_spawn_file_actions_init() seems to have been misplaced here regarding initializing an already initialized object. The missing paragraph is accidentally on line 26754 of page 853. Action: Add paragraph (from .1d): The effect of initializing an already initialized spawn file actions object is undefined. Delete this paragraph from line 26754 of page 853. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 451 prindle@voicenet.com Bug in XSHd3 (rdvk# 653) [prindle.xsh-23] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note with the problem statement/action in it _____________________________________________________________________________ Page: 853 Line: 26754 Section: posix_spawnattr_destroy() Problem: Bob Barned has already identified a similar inconsistency in POSIX.1c, that is it is not clear if it is permissible to reinitialize an already initialized thread attribute object. It would seem clear from the presence of the destroy operation that such a thing should result in undefined behavior, but it should be clearly stated here, for posix_spawnattr_init() as it was for posix_spawn_file_actions_init(). Action: Add in place of this erroneous line: "The effect of initializing an already initialized spawn attributes object is undefined." If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 452 prindle@voicenet.com Bug in XSHd3 (rdvk# 655) Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 857 Line: 26851-26853 Section: posix_spawnattr_getflags() [prindle.xsh-25] Problem: No shading for optional text. Action: Replace "and POSIX_SPAWN_SETSIGMASK. In addition, if the Process Scheduling option is supported, the flags" with "POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSCHEDPARAM, and POSIX_SPAWN_SETSCHEDULER". Shade the last two flags, and use margin code PS. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 453 prindle@voicenet.com Bug in XSHd3 (rdvk# 656) Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 861 Line: 26938,26939 Section: posix_spawnattr_getschedparam() [prindle.xsh-26] Problem: POSIX.1d specified these two includes in the opposite order. This problem also applies to: page 863 line 26987,26988 section posix_spawnattr_getschedpolicy() Action: Reverse the order of these includes for consistency with the base standard. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 454 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 629) [DWC-40] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 875 Line: 27177 Section: posix_typed_mem_get_info Problem: (posix_typed_mem_get_info: Description) The info parameter to the posix_typed_mem_get_info() function is a pointer to a structure, not a structure. Therefore, info.posix_tmi_length is not correct C-language syntax. Action: Change "info.posix_tmi_length" on P875, L27177 to "info->posix_tmi_length". ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 455 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 152) [tog-c99-xsh 128] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept___X_ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 880 Line: 27323 Section: pow Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Add after line 27323: float powf(float x, float y); long double powl(long double x, long double y); [Ed note: Add to CH The powf() and powl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 456 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 153) [tog-c99-xsh 129] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The pow( ) function ..." To "The pow(), powf() and powl() functions ..." Same change on lines 27344 and 27347. _____________________________________________________________________________ Page: 880 Line: 27328 Section: pow Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Change "The pow( ) function ..." To "The pow family of functions ..." Same change on lines 27344 and 27347. _____________________________________________________________________________ objection Enhancement Request Number 457 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 154) [tog-c99-xsh 130] 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, pow( ) ..." To "Upon successful completion, the pow(), powf() and powl() functions ..." _____________________________________________________________________________ Page: 880 Line: 27333 Section: pow Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Change "Upon successful completion, pow( ) ..." To "Upon successful completion, the pow family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 458 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 250) [tog-c99-xsh 224] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 883 Line: 27386 Section: printf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.3). Action: Change "int printf(const char * format, ...);" To "int printf(const char * restrict format, ...);" [Ed note: Add to CH The printf() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ comment Enhancement Request Number 459 prindle@voicenet.com Bug in XSHd3 (rdvk# 654) [prindle.xsh-24] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Insert a revnote with the problem statement _____________________________________________________________________________ Page: 886 Line: 27488 Section: pthread_attr_destroy() Problem: Bob Barned identified that the treatment of this kind of attribute object is inconsistent with other such attribute objects in .1c. Namely, it is unclear what the effect of initializing an already initialized thread attributes object is. Action: Add: "The effect of initializing an already initialized thread attributes object is undefined." If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 460 donnte@microsoft.com Bug in XSHd3 (rdvk# 555) [DT-XSH-123] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 886 Line: 27495 Section: pthread_attr_destroy Problem: shallification (and I suspect I missed many of these; editor fix all). Action: "These functions do not" -> "These functions shall not" (This is a requirement on the implementation, right?) _____________________________________________________________________________ comment Enhancement Request Number 461 prindle@voicenet.com Bug in XSHd3 (rdvk# 657) Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove the revnote _____________________________________________________________________________ Page: 912 Line: 28030-28034 Section: pthread_barrier_destroy() [prindle.xsh-27] Problem: I don't understand this Note to Reviewers at all. This problem also applies to: page 1043 line 31691-31696 section pthread_spin_destroy() Action: Explain what all this means. I can't see any difference between how this is handled here (may fail) from any other init/destroy pair. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 462 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 13) {drb-2} Mon, 10 Apr 2000 18:36:37 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 933 Line: 28650 Section: pthread_cond_init 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. The description of the sem_init() function says that "Only sem itself may be used for performing synchronization. The result of referring to copies of sem in calls to sem_wait, sem_trywait, sem_post, and sem_destroy, is undefined." PASC 1003.1c Interpretation Request #34 points out that similar text should have been included in the description of pthread_mutex_init() and pthread_cond_init(), but was inadvertently omitted. The response of the interpretations committee (chaired by a certain Andrew Josey) was that the intent of the working group was that mutex and condition variable operations on copies of the synchronization objects should be undefined. Action: The Austin Group is now the working group in care of the 1003.1c amendment revisions, and it is therefore the responsibility of this group to make the appropriate changes to the standard. Before line 28650, insert the following paragraph: "Only cond itself may be used for performing synchronization. The result of referring to copies of cond in calls to pthread_cond_wait, pthread_cond_timedwait, pthread_cond_signal, pthread_cond_broadcast, and pthread_cond_destroy, is undefined." [Ed note: Add to CH The DESCRIPTION is updated for IEEE PASC Interpretation 1003.1c #34] _____________________________________________________________________________ objection Enhancement Request Number 463 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 21) {drb-4} Fri, 14 Apr 2000 15:09:14 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 939 Line: 28814 Section: pthread_cond_timedwait 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. The description of pthread_cond_[timed]wait, under errors, specifies that the functions may return a value of EINVAL to indicate that "the mutex was not owned by the current thread at the time of the call". The pthread_mutex_unlock function specifies that the identical error may be reported by returning EPERM. The EPERM error makes much more sense; both because it better describes the error and because it's distinguishable from the other two EINVAL causes. Action: The response of the interpretations committee was that the EINVAL return for pthread_cond_[timed]wait "is not what was intended". The description of pthread_cond_[timed]wait should assign this error condition, ("mutex not owned by the current thread at the time of the call"), to the error code EPERM. [EPERM] The mutex was not owned by the current thread at the time of the call. [Ed note: Add to CH The ERRORS section has an additional case for [EPERM] for IEEE PASC Interpretation 1003.1c #28] _____________________________________________________________________________ objection Enhancement Request Number 464 prindle@voicenet.com Bug in XSHd3 (rdvk# 670) [prindle.xsh-40] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 964 Line: 29480 Section: pthread_getschedparam() Problem: During the merge of 1003.1d the word "of" in this line was used to replace the word "for" in 1003.1d. While this sentence is confusing at best, changing this to "of" makes it worse. Action: Restore the phrase as it was in 1003.1d: "with the exception for the pthread_setschedparam() function that...". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 465 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 22) {drb-5} Fri, 14 Apr 2000 15:23:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the paragraph at line 29691 to read: ----------- An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits. ----------- Add to CH The DESCRIPTION is updated for IEEE PASC Interpretation 1003.1c #8 _____________________________________________________________________________ Page: 971 Line: 29691 Section: pthread_cond_timedwait 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. The description of thread-specific data destructors current implies a requirement on conforming destructor routines to clear the value of the key (to call pthread_setspecific with a value of NULL) in order to avoid a possible infinite loop during thread termination. This requirement arises because the original statement that the implementation would set the value of the key for the terminating thread to NULL, prior to calling the destructor, was inadvertently removed during editing of a draft. This requirement is unreasonable. There is no need to, nor benefit in, forcing the destructor to take this action. Furthermore, the destructor routine is given only the current thread's value for the key, not the pthread_key_t itself, needlessly reducing generality. (E.g., it would be reasonable to specify "free" as the destructor for any number of thread-specific data keys where the only cleanup action necessary was to free storage.) Action: The interpretations committee determined that the standard should be changed to require that the implementation set the value of the thread-specific data key, for the calling thread, to NULL prior to calling the destructor. This was the original intent of the working group. Change the paragraph at line 29691 to read: ----------- An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits. ----------- It should also be noted on page 966, paragraph at line 29548, that calling pthread_getspecific within a destructor for the key being destroyed will return the value NULL rather than the value passed as an argument. (Unless pthread_setspecific has been called within the destructor routine to set a new value.) _____________________________________________________________________________ Objection Enhancement Request Number 466 donnte@microsoft.com Bug in XSHd3 (rdvk# 556) [DT-XSH-124] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: We asked an expert - there are programs that depend on the thread terminating although the number of non null pointers is not decreasing. _____________________________________________________________________________ Page: 971 Line: 29696 Section: pthread_key_create Problem: (This was actioned on me last time, but never made a list of AIs, so I lost it until now. If an expert doesn't show up this time, I'll take the AI again (but request that it be recorded as such.)) Is it reasonable to require that the number of non-NULL destructor values decrease with each one, n or PTHREAD_DESTRUCTOR_INTERACTIONS or a loop is declared and the process of calling destructors stopped as a lost cause. Action: Ask experts. _____________________________________________________________________________ objection Enhancement Request Number 467 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 14) {drb-3} Mon, 10 Apr 2000 18:39:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 978 Line: 29925 Section: pthread_mutex_init 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. The description of the sem_init() function says that "Only sem itself may be used for performing synchronization. The result of referring to copies of sem in calls to sem_wait, sem_trywait, sem_post, and sem_destroy, is undefined." PASC 1003.1c Interpretation Request #34 points out that similar text should have been included in the description of pthread_mutex_init() and pthread_cond_init(), but was inadvertently omitted. The response of the interpretations committee (chaired by a certain Andrew Josey) was that the intent of the working group was that mutex and condition variable operations on copies of the synchronization objects should be undefined. Action: The Austin Group is now the working group in care of the 1003.1c amendment revisions, and it is therefore the responsibility of this group to make the appropriate changes to the standard. Before line 29925, insert the following paragraph: "Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock, and pthread_mutex_destroy, is undefined." [Ed note: Add to CH The DESCRIPTION is updated for IEEE PASC Interpretation 1003.1c #34] _____________________________________________________________________________ Objection Enhancement Request Number 468 donnte@microsoft.com Bug in XSHd3 (rdvk# 557) [DT-XSH-125] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: can on 29927 is correct. On 29928, change is->shall be _____________________________________________________________________________ Page: 978 Line: 29926 Section: pthread_mutex_destroy Problem: shallification (and de-can-ing). Action: Replace paragraph: In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER may be used as a static initializer. The effect shall be equivalent to dynamic initialization... (as was). _____________________________________________________________________________ comment Enhancement Request Number 469 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 389) {drb-6} Fri, 14 Apr 2000 19:11:21 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 993 Line: 30386 Section: pthread_mutexattr_init 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. The ENOMEM error return for pthread_mutexattr_init is documented as "if detected" in POSIX-speak, which translates to "may fail if" in SUS-speak. However, the ENOMEM error for the sibling routines pthread_cond_attr_init and pthread_attr_init are documented as "if occurs" (shall fail if). (As is the SUS pthread_rwattr_init, for that matter.) The inconsistency itself is bad enough, but this also violates the philosophy that was intended to separate "if occurs" from "if detected". Conditions that are not programming errors, that a reasonable programmer cannot be expected to have predicted, or avoided merely by "good programming" must be detected and reported by the implementation. ENOMEM errors are a classic example of this category. Action: In the response to POSIX 1003.1 interpretations request #27, the interpretations committee conceded that this was an inconsistency that should be addressed in the standard. The recommended solution is to change the description of the ENOMEM error from "may fail if" to "shall fail if": The pthread_mutexattr_init() function shall fail if: [ENOMEM] Insufficient memory exists to initialize the mutex attributes object. [Ed note: Add to CH The ERRORS section is updated for IEEE PASC Interpretation 1003.1c #27] _____________________________________________________________________________ Objection Enhancement Request Number 470 donnte@microsoft.com Bug in XSHd3 (rdvk# 558) Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 995 Line: 30479 Section: pthread_mutexattr_destroy [DT-XSH-126] Problem: C does not contain a right-arrow operator (as a single character). (Throughout this example.) Action: Replace right arrows with the correct dash-hyphen. (If this is a property of the postscript print process I used, then some action must be taken to prevent that... e.g. a 0-width space.) _____________________________________________________________________________ objection Enhancement Request Number 471 ajosey@opengroup.org Bug in XSHd3 (rdvk# 409) {bwg2000-003} Sun, 30 Apr 2000 08:38:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 901 Line: 127877 Section: pthread_attr_getstackaddr Problem: The Open Group Base Working Group has approved resolution BWG2000-003 (see http://www.opengroup.org/platform/resolutions/ ). This is included below, and puts forward two new functions for additions as XSI functions in the revision. 2000 #003r2 _____________________________________________________________________________ Topic: pthreads stack handling Relevant Sections: pthread_ Spec: XSH5 Resolution Request: ------------------- POSIX 1003.1c included an optional feature known as the "stackaddr" attribute, manipulated using the pthread_attr_setstackaddr() and pthread_attr_getstackaddr() functions. This optional features was designed to allow an application to create and manage its own stacks. PROBLEM STATEMENT: There are some problems with the "stackaddr" attribute, stemming from the fact that the standard does not provide any way to specify the size of the application-managed stack. 1. The implementation cannot know the size without guessing, or utilizing some non-standard mechanism. 2. The standard does not specify, or even suggest, the relationship between the specified address and the actual base of the thread's stack. There various possibilities, depending on whether the machine modifies a stack pointer before or after storing data, and whether it increases or decreases the stack pointer. (There are more than the obvious four combinations because on Intel's IA-64 architecture each thread has two independent stacks, one of which grows UP while the other grows DOWN.) An implementation can only make one "guess" about the stack's size that's remotely supported by the standard: that the stack is precisely PTHREAD_STACK_MIN bytes. This, however, is not useful because, by definition, that is a "minimal" size, not even a "typical" size. There's little value to an application in being able to "manage its own stacks" if it can do so only for stacks of the architecturally minimum size. The only suggestion provided by the standard for a means to specify the size of a "stackaddr" stack is to presume a connection between the "stackaddr" and "stacksize" attributes. No such connection, however, is specified, or even explicitly allowed, by the standard. Therefore, any application depending on such a connection is non-portable. To require such a connection now would break existing applications, where the value of "stacksize" that happens to be in an attributes object could suddenly become an actual limit. Furthermore, there's little value to improving the situation unless we define "stackaddr" in a way that would become portable, such as specifying that it be the low address of the stack. Such a change would also break existing code on real implementations. (For example, Tru64 UNIX, where "stackaddr" must specify the address immediately following the stack buffer because the stack grows down and the pointer is decreased before storing data.) PROPOSED SOLUTION: The "stackaddr" attribute should be marked "obsolete", and should be replaced by an attribute that's clear, useful, and can be used portably, such as the proposed "stack" attribute. An application-managed stack is specified using the low memory address (e.g., the address returned by malloc, or mmap), and a size. The implementation can position the thread's initial stack pointer(s) where necessary and appropriate within that region, without guessing, and without additional assistance from the application. The "stack" attribute is intended to be MINIMAL, not COMPREHENSIVE. For example, it has frequently been assumed that applications can provide stack overflow protection with a protected page (or pages) outside the described area. However, no fully portable application can do this, because it would still need to know at which end of the stack the protected page should go. While it could place protected pages at both ends, an implementation on Intel's IA-64 is likely to create two separate stacks that grow towards the center of the provided region. It would be possible to extend the stack attribute interface, either by adding a parameter or by specifying a connection with the "guardsize" attribute, to cause the implementation to provide appropriate guard page(s) for the application stack. (I'd prefer to avoid such a connection, because experience has shown, as with policy and priority, and expecially inheritsched, that this causes programmer confusion and unnecessary support calls.) I am not proposing either extension, but I would not object to adding a "guardsize" parameter to the "stack" attribute functions. Resolution Response ------------------- Two new functions will be added to a future revision of the specification. A new manual page is attached. This is an XSI extension. NAME pthread_attr_getstack, pthread_attr_setstack - get and set stack attribute SYNOPSIS #include int pthread_attr_getstack(const pthread_attr_t *attr, void **stackaddr, size_t *stacksize); int pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr, size_t stacksize); DESCRIPTION The functions pthread_attr_getstack() and pthread_attr_setstack(), respectively, shall get and set the thread creation stack attribute in the attr object. The stack attribute specifies the area of storage to be used for the created thread's stack. The base (lowest addressable byte) of the storage is stackaddr, and the size of the storage is stacksize bytes. The stacksize shall be at least PTHREAD_STACK_MIN. The stackaddr shall be aligned appropriately to be used as a stack; for example, pthread_attr_setstack may fail with EINVAL if (stackaddr & 0x7) is not 0. All pages within the stack described by stackaddr and stacksize shall be both readable and writeable by the thread. RETURN VALUE Upon successful completion, pthread_attr_getstack() and pthread_attr_setstack() shall return a value of 0; otherwise, an error number shall be returned to indicate the error. The pthread_attr_getstack() function shall store the stack attribute values in stackaddr and stacksize if successful. ERRORS The pthread_attr_setstack() function shall fail if: [EINVAL] The value of stacksize is less than PTHREAD_STACK_MIN or exceeds a system-imposed limit. The pthread_attr_setstack() function may fail if: [EINVAL] The value of stackaddr does not have proper alignment to be used as a stack, or if (stackaddr + stacksize) lacks proper alignment. [EACCES] The stack page(s) describe by stackaddr and stacksize are not both readable and writeable by the thread. These functions shall not return an error code of [EINTR]. EXAMPLES None. APPLICATION USAGE These functions are appropriate for use by applications in an environment where the stack for a thread must be placed in some particular region of memory. While it might seem that an application could detect stack overflow by providing a protected page outside the specified stack region, this cannot be done portably. Implementations are free to place the thread's initial stack pointer anywhere within the specified region to accomodate the machine's stack pointer behavior and allocation requirements. Furthermore, on some architectures, such as the IA-64 , "overflow" might mean that two separate stack pointers allocated within the region will overlap somewhere in the middle of the region. FUTURE DIRECTIONS None. SEE ALSO pthread_attr_init(), pthread_attr_setdetachstate(), pthread_attr_setstacksize(), pthread_create(), , . Rationale ------------- See the problem statement. Circulated for review: 26 Apr 2000 Proposed resolution: 26 Apr 2000 Approved: April 2000 Action: Add the new manual page included in the resolution above. _____________________________________________________________________________ Objection Enhancement Request Number 472 donnte@microsoft.com Bug in XSHd3 (rdvk# 559) [DT-XSH-127] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: the review group did not agree with the problem and since wording is from a base document rejected this. note MAN shading is incorrect, and should not be shaded at 30654 _____________________________________________________________________________ Page: 1000 Line: 30654 Section: putenv (This was actioned on me last time to create an interp request, but never made a list of AIs, so I lost it until now. If it is not resolved this time, I'll take the AI again (but request that it be recorded as such.)) This paragraph refers to "moving to the end of the scheduling queue", which I presume refers to line 26741 of sched_setparam(), but with which it shares no common terminology. As worded, this sets things up for an interpretation request. Action: Instead of "moving to the tail of the scheduling queue"... change (starting at the *): "While a thread is holding...protocol attributes *it shall not subject to the requirement that it resume execution after all other runnable processes at equal or greater priority have been scheduled to run as required by sched_setparam() and similar calls". (2 places). Also, add at 34508 (in sched_setparam): "except as specified under pthread_mutexattr_getprotocol()". _____________________________________________________________________________ comment Enhancement Request Number 473 prindle@voicenet.com Bug in XSHd3 (rdvk# 658) [prindle.xsh-28] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1014 Line: 30996 Section: pthread_rwlock_destroy() Problem: It isn't clear when a process would not have such privilege. This is not in POSIX .1j. If it is included here, it ought to be marked MAN or something like that to indicate that it is an extension to POSIX, and the description should indicate when such a failure might occur. Action: Shade this line MAN. Modify description to indicate what might fail without sufficient privilege. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 474 prindle@voicenet.com Bug in XSHd3 (rdvk# 659) [prindle.xsh-29] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: w/d by Frank _____________________________________________________________________________ Page: 1017 Line: 31043 Section: pthread_rwlock_rdlock() Problem: It is not clear why these two POSIX options should be merged into one. Action: I'll support this if it can be proven that no RT profile that supports threads couldn't do without this (coordinate with Michael Gonzalez and SSWG-RT proposal for 1003.13b at July POSIX meeting). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 475 prindle@voicenet.com Bug in XSHd3 (rdvk# 660) Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: marked up on the draft, changes to 31266 and 31064 to be consistent with this wording. _____________________________________________________________________________ Page: 1019 Line: 31149 Section: pthread_rwlock_timedrdlock() [prindle.xsh-30] Problem: Elsewhere, wording regarding the potential for deadlock was changed to indicate that deadlock may either occur or be detected, but not here. This problem also applies to: page 1021 line 31210 section pthread_rwlock_timedwrlock() Action: Change the first sentence (31149) to: Results are undefined if the calling thread holds a write lock on rwlock at the time the call is made. Change the second sentence (31210) to: Results are undefined if the calling thread holds the read-write lock (whether a read or write lock) at the time the call is made. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 476 donnte@microsoft.com Bug in XSHd3 (rdvk# 560) [DT-XSH-128] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add app usage that the setenv() function is the preferred function _____________________________________________________________________________ Page: 1056 Line: 31975 Section: putenv Problem: Given the several weaknesses of this interface: particularly the business of not copying the string so it ends up actually in the environment in a fragile state... and the undefined nature of the interface when an "=" is omitted.... This should be made a Legacy interface indicating preference for setenv(), which is a better interface providing similar functionality. Action: Make legacy, add note preferring setenv. _____________________________________________________________________________ Objection Enhancement Request Number 477 donnte@microsoft.com Bug in XSHd3 (rdvk# 561) [DT-XSH-129] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: marked up _____________________________________________________________________________ Page: 1069 Line: 32347 Section: raise Problem: The changes applied for threads have broken this interface for the non-thread case. Action: 1) Restore all original text to refer to processes and conventional kill(). 2) *ADD*: if threads are defined on the implementation then . _____________________________________________________________________________ objection Enhancement Request Number 478 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 217) [tog-c99-xsh 191] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The raise( ) function shall send the signal sig to the executing thread." To "The raise( ) function shall send the signal sig to the executing [CX thread or process ]. If a signal handler is called, the raise() function shall not return until after the signal handler does." _____________________________________________________________________________ Page: 1069 Line: 32348 Section: raise Problem: Change required for alignment with C99 (ref C99 section 7.14.2.1). Action: Change "The raise( ) function shall send the signal sig to the executing thread." To "The raise( ) function shall send the signal sig to the executing thread. If a signal handler is called, the raise() function shall not return until after the signal handler does." _____________________________________________________________________________ Objection Enhancement Request Number 479 donnte@microsoft.com Bug in XSHd3 (rdvk# 562) [DT-XSH-130] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: ISO C requires this function. Add the See Also to initstate() _____________________________________________________________________________ Page: 1072 Line: 32465 Section: rand Problem: This makes a nice case for making this a legacy function (or just deleting it). Action: Preferably delete, if not make legacy. If retained, add random() (or rather initstate()) to the references. _____________________________________________________________________________ Objection Enhancement Request Number 480 donnte@microsoft.com Bug in XSHd3 (rdvk# 563) [DT-XSH-131] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1083 Line: 32843 Section: readdir Problem: EMB Text here is duplicated at 32868. Action: Delete at 32868. _____________________________________________________________________________ Objection Enhancement Request Number 481 donnte@microsoft.com Bug in XSHd3 (rdvk# 564) [DT-XSH-132] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 1) Remove CX and shading here _____________________________________________________________________________ Page: 1091 Line: 33069 Section: realloc Problem: The text marked CX is in fact NOT CX. The text appears verbatim at [345].10.3 (depending on your edition of the C standard) in a place that applies to the whole malloc family. Given the rearrangement of the document, either realloc() should be folded in with malloc, or the shading removed. Action: 1) Remove CX and shading here and any other places it appears w.r.t. this text. (Or recombine with malloc()). 2) Check other CX shading for this sort of problem. _____________________________________________________________________________ Objection Enhancement Request Number 482 donnte@microsoft.com Bug in XSHd3 (rdvk# 565) [DT-XSH-133] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the reviewers do not agree with the problem _____________________________________________________________________________ Page: 1095 Line: 33182 Section: recv Problem: recv(), recvfrom() and recvmsg() are sufficiently different to justify a separate page for each, but it's very difficult to glean from the three pages what the core of the difference might be. Action: Add as the first paragraph of each of the three sections a statement as to the purpose of that interface. (If someone can do better, that's fine with me.) For recv: at 33182. Change the first sentence to read Receive a message from a socket which is actually connected. The socket may be connection-mode or connectionless-mode. For recvfrom: at 33263 Change the first sentence to read Receive a message from a socket, obtaining the source information via command line arguments. The socket need not be connected, and may be connection-mode or connectionless-mode. For recvmsg: at 33356 Change the first sentence to read Receive a message from a socket, obtaining the source information via a structure. The socket need not be connected, and may be connection-mode or connectionless-mode. _____________________________________________________________________________ comment Enhancement Request Number 483 prindle@voicenet.com Bug in XSHd3 (rdvk# 661) [prindle.xsh-31] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This was completed in a separate action post the meeting and actioned into D4. _____________________________________________________________________________ Page: 1096 Line: 33217-33240 Section: recv() Problem: recv() is essentially a read() with socket specific flags and some socket specific errors not returned by read(). Some of the errors here (and not in read()) would seem to be in common with read, especially when either is used to read from a connection oriented socket: EFAULT ENOMEM ENOSR Also note that EIO is may fail here, and shall fail in read(). In fact, APP USAGE implies identity with read() when no flags are specified, yet read() has a smaller error set when reading from sockets. This problem also applies to: page 1175-1176 line 35865-35892 section send() Action: Consider harmonizing the set of errors between recv() and read() where the errors have nothing to do with the flags. I know this is vague, but don't fully understand the rationale regarding why these errors were not applied to read() by XNS when reading from a socket. Same applies to send() and write(). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 484 prindle@voicenet.com Bug in XSHd3 (rdvk# 662) [prindle.xsh-32] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1100 Line: 33387-33388 Section: recvmsg() Problem: Several references to rcvfrom() that appear they should be to rcvmsg(). Action: Replace any rcvfrom() function references in this section with rcvmsg() (except in SEE ALSO of course). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 485 donnte@microsoft.com Bug in XSHd3 (rdvk# 566) [DT-XSH-134] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete REG_ENOSYS here and mark as LEGACY in XBD. Similarly for FNM_ENOSYS. (and in Return Value [2 places]) _____________________________________________________________________________ Page: 1105 Line: 33565 Section: regcomp() Problem: I thought we were getting rid of ENOSYS type errors. Certainly in the case of something that's likely to be a library a stub is particularly useless. Action: Delete REG_ENOSYS. _____________________________________________________________________________ objection Enhancement Request Number 486 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 189) [tog-c99-xsh 163] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1111 Line: 33760 Section: remainder Problem: Change required for alignment with C99 (ref C99 section 7.12.10.2). Action: Add after line 1111: float remainderf(float x, float y); long double remainderl(long double x, long double y); [Ed note: Add to CH The remainderf() and remainderl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 487 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 190) [tog-c99-xsh 164] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The remainder( ) function ..." To "The remainder(), remainderf() and remainderl() functions ..." Same change on lines 33768, 33773 and 33775. _____________________________________________________________________________ Page: 1111 Line: 33763 Section: remainder Problem: Change required for alignment with C99 (ref C99 section 7.12.10.2). Action: Change "The remainder( ) function ..." To "The remainder family of functions ..." Same change on lines 33768, 33773 and 33775. _____________________________________________________________________________ objection Enhancement Request Number 488 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 191) [tog-c99-xsh 165] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 1114 Line: 33847 Section: remquo Problem: Change required for alignment with C99 (ref C99 section 7.12.10.3). Action: Add the following entry after line 33847: NAME remquo - remainder functions SYNOPSIS #include double remquo(double x, double y, int *quo); float remquof(float x, float y, int *quo); long double remquol(long double x, long double y, int *quo); 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 remquo() functions shall compute the same remainder as the remainder() functions. In the object pointed to by quo they store a value whose sign is the sign of x/y and whose magnitude is congruent modulo 2**n to the magnitude of the integral quotient of x/y, where n is an implementation-dependent integer greater than or equal to 3. 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 remquo() functions shall return x REM y. When y is 0, the remquo() functions shall return NaN (or equivalent if available) and set errno to [EDOM]. If the value of x is 1Inf, the remquo() functions shall return NaN and set errno to [EDOM]. If x or y is NaN, then the functions shall return NaN and errno may be set to [EDOM]. ERRORS The remquo() functions shall fail if: [EDOM] The y argument is 0 or the x argument is positive or negative infinity. The remquo() functions may fail if: [EDOM] The x or y argument is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE The remquo functions are intended for implementing argument reductions which can exploit a few low-order bits of the quotient. Note that x may be so large in magnitude relative to y that an exact representation of the quotient is not practical. FUTURE DIRECTIONS None. SEE ALSO remainder(), 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 489 donnte@microsoft.com Bug in XSHd3 (rdvk# 567) [DT-XSH-135] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove the reviewers note. Restore the missing "," between "refer to" and "and link to". _____________________________________________________________________________ Page: 1115 Line: 33867 Section: rename Problem: (This was left open last time, and I see no resolution.) I think this is editorial, but it may be more than that. Either "both refer to and both link to" is redundant, or it's saying something I'm totally missing. If it's redundant, delete one clause. If not, then this is an objection and since I haven't a clue what IS meant, I can't suggest a fix. Action: Delete one clause (or fix so the import is clear). _____________________________________________________________________________ Objection Enhancement Request Number 490 donnte@microsoft.com Bug in XSHd3 (rdvk# 568) [DT-XSH-136] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: this is the approved ISO/IEEE terminology _____________________________________________________________________________ Page: 1115 Line: 33869 Section: rename Problem: Also 33875. "Application shall ensure" again burdens the application unnecessarily and wrongly. Action: Restore original .1 use of shall. _____________________________________________________________________________ objection Enhancement Request Number 491 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 178) [tog-c99-xsh 152] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1124 Line: 34131 Section: rint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Add after line 34131: float rintf(float x); long double rintl(long double x); [Ed note: Add to CH The rintf() and rintl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 492 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 180) [tog-c99-xsh 154] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The rint( ) function ..." To "The rint(), rintf() and rintl() functions ..." Same change on line 34145. _____________________________________________________________________________ Page: 1124 Line: 34134 Section: rint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Change "The rint( ) function ..." To "The rint family of functions ..." Same change on line 34145. _____________________________________________________________________________ objection Enhancement Request Number 493 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 179) [tog-c99-xsh 153] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1124 Line: 34134 Section: rint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Remove XSI annotation from entry and add the following text after line 34134: 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. [Ed note: Add to CH The rint() function is no longer marked XSI as it is part of ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 494 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 181) [tog-c99-xsh 155] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the folowing text after line 34138: The rint(), rintf() and rintl() functions differ from the nearbyint(), nearbyintf() and nearbyintl() functions only in that they may raise the inexact floating-point exception if the result differs in value from the argument. _____________________________________________________________________________ Page: 1124 Line: 34138 Section: rint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Add the folowing text after line 34138: The rint() functions differ from the nearbyint() functions only in that the rint() functions may raise the inexact floating-point exception if the result differs in value from the argument. _____________________________________________________________________________ objection Enhancement Request Number 495 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 182) [tog-c99-xsh 156] 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, rint( ) ..." To "Upon successful completion, the rint(), rintf() and rintl() functions ..." _____________________________________________________________________________ Page: 1124 Line: 34140 Section: rint Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "Upon successful completion, rint( ) ..." To "Upon successful completion, the rint family of functions ..." _____________________________________________________________________________ editorial Enhancement Request Number 496 al.simons@compaq.com Bugs in XSHd3 (rdvk# 369) {compaq-aks-003} Tue, 25 Apr 2000 10:47:43 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1125 Line: 34201-34202 Section: rmdir Problem: The description of error ENAMETOOLONG has an extra paragraph break between "...is longer than" and "NAME_MAX..." Action: Remove the extra paragraph break. _____________________________________________________________________________ Editorial Enhancement Request Number 497 Don.Cragun@eng.sun.com Bug in XSHd3 (rdvk# 630) [DWC-41] Mon, 1 May 2000 23:12:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1126 Line: 34242 Section: rmdir Problem: (rmdir: typo in rationale) Missing apostrophe. Action: Change "processs" on P1126, L34242 to "process's". ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 498 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 184) [tog-c99-xsh 158] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 1128 Line: 34290 Section: round Problem: Change required for alignment with C99 (ref C99 section 7.12.9.6). Action: Add the following entry after line 34290: NAME round - round to nearest integer value in floating-point format SYNOPSIS #include double round(double x); float roundf(float x); long double roundl(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 round() functions shall round their argument to the nearest integer value in floating-point format, rounding halfway cases away from zero, regardless of the current rounding direction. 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 round() functions shall return the rounded integer value. If x is 1Inf, the round() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The round() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. 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 499 donnte@microsoft.com Bug in XSHd3 (rdvk# 569) [DT-XSH-137] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: same change as for ilogb _____________________________________________________________________________ Page: 1129 Line: 34299 Section: scalb Problem: I'd still rather it was deleted as pretty useless (See ERN 296). However, at least add SEE ALSO to logb() and ilogb() Also, to make effective use of this call, the programmer needs to know "r", which is FLT_RADIX in float.h Action: Add at 34299: The value of r is FLT_RADIX found in float.h Add logb(), ilogb(), float.h to SEE ALSO section. _____________________________________________________________________________ objection Enhancement Request Number 500 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 144) [tog-c99-xsh 120] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 1129 Line: 34329 Section: scalbn Problem: Change required for alignment with C99 (ref C99 section 7.12.6.13). Action: Add the following entry after line 34329: NAME scalbn - compute exponent using FLT_RADIX SYNOPSIS #include double scalbn(double x, int n); float scalbnf(float x, int n); long double scalbnl(long double x, int n); double scalbln(double x, long int n); float scalblnf(float x, long int n); long double scalblnl(long double x, long int n); 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 scalbn() and scalbln() functions shall compute x*FLT_RADIX**n efficiently, not normally by computing FLT_RADIX**n explicitly. 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 Upon successful completion, the scalbn() and scalbln() functions shall return x*FLT_RADIX**n. If the correct value would overflow, the scalbn() and scalbln() functions shall return 1HUGE_VAL (according to the sign of x) and set errno to [ERANGE]. If the correct value would underflow, the scalbn() and scalbln() functions shall return 0 and set errno to [ERANGE]. The scalbn() and scalbln() functions shall return x when x is 1Inf. If x or n is NaN, then the scalbn() and scalbln() functions shall return NaN and may set errno to [EDOM]. ERRORS The scalbn() and scalbln() functions shall fail if: [ERANGE] The correct value would overflow or underflow. The scalbn() and scalbln() functions may fail if: [EDOM] The x or n argument is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In earlier versions of the C specification, this function was called scalb. The name was changed to avoid conflicting with the Single Unix scalb function whose second argument is double instead of int. Single Unixs scalb was not included in C9X as its specification of certain special cases is inconsistent with the C9X approach and because the scalbn and scalbln functions were considered sufficient. scalbln, whose second parameter has type long int is provided because the factor required to scale from the smallest positive floating-point value to the largest finite one, on many implementations, is too large to represent in the minimum-width int format. FUTURE DIRECTIONS None. SEE ALSO scalb(), 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 501 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 251) [tog-c99-xsh 225] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1130 Line: 34334 Section: scanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.4). Action: Change "int scanf(const char * format, ... );" To "int scanf(const char * restrict format, ... );" [Ed note: Add to CH The scanf() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 502 donnte@microsoft.com Bug in XSHd3 (rdvk# 570) [DT-XSH-138] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add a revnote with the problem statement _____________________________________________________________________________ Page: 1135 Line: 34533 Section: sched_setparam Problem: (This was left open last time, and I see no resolution.) I don't understand what "including SCHED_OTHER" is trying to say... if it's just another "or" then it's strangely phrased. If not, I'm completely baffled. Action: Get resolution from expert or add Editor's note. _____________________________________________________________________________ Editorial Enhancement Request Number 503 donnte@microsoft.com Bug in XSHd3 (rdvk# 571) [DT-XSH-139] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "kernel scheduled" -> "kernel-scheduled" everywhere in these 3 paragraphs, and remove the revnote _____________________________________________________________________________ Page: 1136 Line: 34551 Section: sched_setparam Problem: These 3 paragraphs are hard to read because of a single (repeated) problem. "kernel scheduled" wants to be mentally parsed very differently than the clearly intended "kernel-scheduled". Action: "kernel scheduled" -> "kernel-scheduled" everywhere in these 3 paragraphs, or rewrite. _____________________________________________________________________________ Comment Enhancement Request Number 504 donnte@microsoft.com Bug in XSHd3 (rdvk# 572) [DT-XSH-140] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1139 Line: 34647 Section: sec_setscheduler Problem: As for sched_setparam (kernel-scheduled) Action: Same substitution as sched_setparam. _____________________________________________________________________________ objection Enhancement Request Number 505 prindle@voicenet.com Bug in XSHd3 (rdvk# 663) [prindle.xsh-33] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add pselect() and from 1003.1g into the next draft _____________________________________________________________________________ Page: 1144 Line: 31778-31784 Section: select() Problem: POSIX.1g, approved but in the process of being withdrawn, indicated that the ballot group supported two differences from what is given here: 1. Require caller to include It is really wierd for to have to include because the relationship is in the opposite direction (select uses timeval, nothing in needs to use select). I know implementations are doing this, but that doesn't make it any less wierd. 2. Add pselect() and deprecate select() select() allows control to return to caller only at 1ms intervals at best when no FD is ready. Every other timed function uses timespec instead of timeval, giving down to 1 nanosecond resolution which is better for RT systems. pselect() adds this capability. Action: Align this page with 1003.1g in these respects. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 506 donnte@microsoft.com Bug in XSHd3 (rdvk# 573) [DT-XSH-141] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The suggested text is not suitable for inclusion here. _____________________________________________________________________________ Page: 1143 Line: 34757 Section: seekdir Problem: 1) Move text from .1-1990, P255, L3014 to here. 2) as a consequence, mark legacy. (Also, telldir()). Action: As above. _____________________________________________________________________________ Comment Enhancement Request Number 507 donnte@microsoft.com Bug in XSHd3 (rdvk# 575) [DT-XSH-143] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1145 Line: 34830 Section: select Problem: Two related topics need to be moved together. Action: Move paragraph at 34849 to 34831; keep all discussion of when a fd is ready together. _____________________________________________________________________________ Comment Enhancement Request Number 508 donnte@microsoft.com Bug in XSHd3 (rdvk# 574) [DT-XSH-142] 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 _____________________________________________________________________________ Page: 1145 Line: 34831 Section: select Problem: (This was left open last time, and I see no resolution.) (This one is even vaguer than most of my vague ones, but the topic needs to be touched upon, or consciously skipped (probably with rationale)). It's not at all unreasonable for a regular file over a network to not be ready at all times. Since network file systems are not discussed in POSIX (yet, that I know of), it may not be useful to make any requirements in this regard. However, networked file systems ARE quite common, and guidance to the implementor of select (and the user) would help with application portability until they are standardized. Action: One or more of: 1) Add rationale suggesting that select on an ordinary file which is on a networked file system may be in a non-ready condition at some times. 2) Delete this paragraph, or weaken it. ("... although files on certain types of file systems may not always be ready.") 3) Add rationale strengthening it so that networked file systems are explicitly disallowed as an exception. Note: Some of the above are mutually contradictory, so choose wisely. _____________________________________________________________________________ Comment Enhancement Request Number 509 donnte@microsoft.com Bug in XSHd3 (rdvk# 576) [DT-XSH-144] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: there is a central description. The action does not supply sufficiently clear editing instructions to enable this move to be made and hence is non-responsive _____________________________________________________________________________ Page: 1155 Line: 35182 Section: select Problem: (This was left open last time, and I see no resolution.) Does this text belong in a central place that discusses scheduling policy? It would make implementation a lot easier if there were not special cases scattered about. (And... as observed above, make maintenance of the standard a lot easier.) Action: Move to central scheduling policy discussion, replace with "The effects on scheduling of this and other processes are discussed in ______". _____________________________________________________________________________ editorial Enhancement Request Number 510 prindle@voicenet.com Bug in XSHd3 (rdvk# 669) [prindle.xsh-39] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: schedule --> scheduling policy _____________________________________________________________________________ Page: 1155 Line: 35187 Section: sem_post() Problem: The work "schedule" is wrong. Action: Change "schedule" to either "scheduler" (consistent with paragraph above) or "scheduling policy" (more consistent with rest of spec). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 511 donnte@microsoft.com Bug in XSHd3 (rdvk# 577) [DT-XSH-145] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: widespread historic use. _____________________________________________________________________________ Page: 1166 Line: 35465 Section: semctl() Problem: The older interfaces are now supplanted by POSIX interfaces. Action: Replace this paragraph with... This standard also defines a set of sem_* functions which should be used for new application development. (Also on 35603, 35805) _____________________________________________________________________________ Objection Enhancement Request Number 512 donnte@microsoft.com Bug in XSHd3 (rdvk# 578) [DT-XSH-146] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: see 482 _____________________________________________________________________________ Page: 1175 Line: 35837 Section: send Problem: send(), sendto() and sendmsg() are sufficiently different to justify a separate page for each, but it's very difficult to glean from the three pages what the core of the difference might be. Action: Add as the first paragraph of each of the three sections a statement as to the purpose of that interface. (If someone can do better, that's fine with me.) For recv: at 35837. *Add* a new first sentence to read Send a message from a socket which is actually connected. The socket may be connection-mode or connectionless-mode. For sendmsg: at 36914 Change the first sentence to read Send a message to a socket, obtaining the destination information via a structure. The socket need not be connected, and may be connection-mode or connectionless-mode. For sendto: at 36025 Change the first sentence to read Send a message to a socket, obtaining the destination information via command line arguments. The socket need not be connected, and may be connection-mode or connectionless-mode. _____________________________________________________________________________ objection Enhancement Request Number 513 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 229) [tog-c99-xsh 203] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1183 Line: 36129 Section: setbuf Problem: Change required for alignment with C99 (ref C99 section 7.19.5.5). Action: Change "void setbuf(FILE * stream, char * buf);" To "void setbuf(FILE * restrict stream, char * restrict buf);" [Ed note: Add to CH The prototype for setbuf is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Comment Enhancement Request Number 514 donnte@microsoft.com Bug in XSHd3 (rdvk# 579) [DT-XSH-147] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1185 Line: 36175 Section: setegid() Problem: Set the effective group ID of *what*? It doesn't say. (Obviously the calling process.) Action: "shall set the effective group ID" -> "\& of the calling process". _____________________________________________________________________________ Objection Enhancement Request Number 515 donnte@microsoft.com Bug in XSHd3 (rdvk# 580) [DT-XSH-148] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add: The strings described by envname and envval are copied by this function. _____________________________________________________________________________ Page: 1186 Line: 36218 Section: setenv Problem: The standard is silent about the fate of the envval and envname strings after setenv() completes. I'd presume that most historical implementations end up copying them into space managed by the *env() functions. This should be codified. Action: Add: The strings described by envval and envname are copied by this function, and may be changed or freed as needed after the function returns. _____________________________________________________________________________ Objection Enhancement Request Number 516 donnte@microsoft.com Bug in XSHd3 (rdvk# 581) [DT-XSH-149] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1188 Line: 36263 Section: seteuid Problem: Of the current process, presumably Action: as for setegid, add "of the calling process" _____________________________________________________________________________ Objection Enhancement Request Number 517 donnte@microsoft.com Bug in XSHd3 (rdvk# 582) [DT-XSH-150] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As for setegid, add "of the calling process" (Applies also to setuid() on line 37084) . _____________________________________________________________________________ Page: 1189 Line: 36295 Section: setgid Problem: EMB "of the current process", in this case as specified in .1-1990. This loss of critical information (even though it is obvious) is embarrassing, and could prove to be serious. This, again, requires that the current official text be vetted against this draft and every unjustified difference resolved in favor of the currently approved standard. Action: As for setegid, add "of the calling process" (Applies also to setuid()). _____________________________________________________________________________ objection Enhancement Request Number 518 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 211) [tog-c99-xsh 185] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the following statement after line 36394: "If the invocation appears in any other context, the behavior is undefined." _____________________________________________________________________________ Page: 1194 Line: 36394 Section: setjmp Problem: Change required for alignment with C99 (ref C99 section 7.13.1.1). Action: Add the following statement after line 36394: "If the Invocation appears in any other context, the behaviour is undefined." _____________________________________________________________________________ Comment Enhancement Request Number 519 donnte@microsoft.com Bug in XSHd3 (rdvk# 583) [DT-XSH-151] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ENOSYS already exists. No action required. _____________________________________________________________________________ Page: 1196 Line: 36446 Section: setkey Problem: This is one of the few places where I'd advocate retaining ENOSYS in the new model... It could reasonably be a system or shared lib function with different US and export versions. Action: Add ENOSYS. _____________________________________________________________________________ comment Enhancement Request Number 520 Sandra O Bug in XSHd3 (rdvk# 381) [compaq-smo-011] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1198 Line: 36491-36492 Section: setlocale Problem: Incomplete information about LC_NUMERIC. Action: Change "Affects the radix character for the formatted input/output functions and the string conversion functions." to "Affects the behavior of functions that handle numeric values." This is similar to the wording for LC_MONETARY (line 34690), and more accurately reflects that there is a bit more to LC_NUMERIC than just the radix character. _____________________________________________________________________________ Objection Enhancement Request Number 521 donnte@microsoft.com Bug in XSHd3 (rdvk# 584) [DT-XSH-152] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add See Also to setpgid(). _____________________________________________________________________________ Page: 1207 Line: 36737 Section: setpgrp Problem: Duplicates setpgid(). Users need to be informed that there's a "more standard" way to achieve the same result. Action: Mark Legacy, add See Also to setpgid(). _____________________________________________________________________________ Editorial Enhancement Request Number 522 donnte@microsoft.com Bug in XSHd3 (rdvk# 585) [DT-XSH-153] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change to "one of the exec family of functions". _____________________________________________________________________________ Page: 1211 Line: 36797 Section: setregid Problem: exec* is not the usual notation for this. Action: Change to "one of the exec functions". _____________________________________________________________________________ Editorial Enhancement Request Number 523 donnte@microsoft.com Bug in XSHd3 (rdvk# 586) [DT-XSH-154] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1219 Line: 36958 Section: setsockopt Problem: spelling Action: "lecel" -> "level" (and font change) _____________________________________________________________________________ comment Enhancement Request Number 524 nick@usenix.org Bug in XSHd3 (rdvk# 18) {Usenix4} Thu, 13 Apr 2000 03:13:21 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1225 Line: 37177 Section: setuid Problem: The cross references should include setreuid(). Similarly for all the functions that handle setting and getting uid and gid values. These are all currently inconsistent. Action: For each of the following interfaces, ensure that the cross references include all of the others: getegid(), getgid(), setegid(), setgid(), setregid(), geteuid(), getuid(), seteuid(), setuid(), setreuid(). _____________________________________________________________________________ objection Enhancement Request Number 525 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 230) [tog-c99-xsh 204] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1227 Line: 37214 Section: setvbuf Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "int setvbuf(FILE * stream, char * buf, int type, size_t size);" To "int setvbuf(FILE * restrict stream, char * restrict buf, int type, size_t size);" [Ed note: Add to CH The setvbuf() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 526 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 231) [tog-c99-xsh 205] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1227 Line: 37220 Section: setvbuf Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "... but before any other operation is performed on the stream." To "... but before any other operation (other than an unsuccessful call to setvbuf()) is performed on the stream." _____________________________________________________________________________ objection Enhancement Request Number 527 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 232) [tog-c99-xsh 206] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1227 Line: 37225-37226 Section: setvbuf Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by setvbuf( ). The argument size specifies the size of the array. ..." To "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by setvbuf( ) and the argument size specifies the size of the array; otherwise, size may determine the size of a buffer allocated by the setvbuf function. ..." _____________________________________________________________________________ Objection Enhancement Request Number 528 donnte@microsoft.com Bug in XSHd3 (rdvk# 587) [DT-XSH-155] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: these functions are in widespread use, often in preference to the POSIX sem_* functions _____________________________________________________________________________ Page: 1239 Line: 37637 Section: shmdt Problem: The older interfaces are now supplanted by POSIX interfaces. Action: Replace this paragraph with... This standard also defines a set of sem_* functions which should be used for new application development. (Also on 37714, and other relevant places.) _____________________________________________________________________________ Comment Enhancement Request Number 529 donnte@microsoft.com Bug in XSHd3 (rdvk# 588) [DT-XSH-156] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the proposed new text is less readable _____________________________________________________________________________ Page: 1246 Line: 37866 Section: sigaction Problem: (This was left open last time, and I see no resolution. This a completely different try at making it clearer. If you like the wording from last time better, use it.) Weak (confusing) language. Action: Rewrite. I'm not sure what was intended, but I can guess, so here's a guess. If set, and if _sig_ equals SIGCHLD, the handling of the termination of child processes of this process changes: rather than being converted into zombies and retained until a member of the wait family of functions is called by the parent, no zombie shall be created. Under these circumstances, if the process calls a member of the wait family of functions, if there are zombie processes (created while SA_NOCHLDWAIT was not in effect) the wait function shall return as specified for the command used when a zombie is present. If no zombie processes remain, members of the wait family shall block until all children of the current process terminate, and then return reporting a failure with errno set to [ECHILD]. [It would be a Very Good Thing if a pointer to this odd behavior was included on the various wait pages.] _____________________________________________________________________________ Comment Enhancement Request Number 530 donnte@microsoft.com Bug in XSHd3 (rdvk# 589) [DT-XSH-157] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1247 Line: 37878 Section: sigaction Problem: This paragraph was in a very different logical place in the original .1-1990 than it is with all these extensions. It's lost its context. (Since there was only one option, .1-1990 was reasonable. With many options, it isn't as much.) Action: Move this paragraph to 37820, and indent it so it's clearly part of the discussion of SA_NOCLDSTOP. _____________________________________________________________________________ Editorial Enhancement Request Number 531 donnte@microsoft.com Bug in XSHd3 (rdvk# 590) [DT-XSH-158] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1248 Line: 37963 Section: sigaction Problem: Case. Action: "this volume" -> "This volume". _____________________________________________________________________________ editorial Enhancement Request Number 532 al.simons@compaq.com Bugs in XSHd3 (rdvk# 368) {compaq-aks-004} | Tue, 25 Apr 2000 10:47:43 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_531 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1248 Line: 37963 Section: sigaction Problem: Missing capitalization for first word of line 37963, "this". Action: Add capitalization. _____________________________________________________________________________ objection Enhancement Request Number 533 al.simons@compaq.com Bugs in XSHd3 (rdvk# 370) {compaq-aks-005} Tue, 25 Apr 2000 10:47:43 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the meaning of the current wording is that if a ss is a null pointer the results are unspecified _____________________________________________________________________________ Page: 1253 Line: 38120 Section: sigaltstack Problem: We specify the function's behavior if ss is not a null pointer, but do not specify the function's behavior if ss *is* a null pointer. A similar situation exists for the oss parameter, but to me at least, it is more obvious what the effect is. Action: Add the following sentence after line 38124: "If ss is a null pointer the current alternate signal stack is unchanged." Add the following sentence at the end of APPLICATION USAGE, page 1254, line 38172: "The application can determine the current alternate signal stack by passing ss as a null pointer." _____________________________________________________________________________ editorial Enhancement Request Number 534 al.simons@compaq.com Bug in XSHd3 (rdvk# 397) {compaq-aks-006} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1253 Line: 38133 Section: sigaltstack Problem: Typo causing number agreement problem in the sentence. "fails" should be "fail". Action: Change "fails" to "fail". _____________________________________________________________________________ Objection Enhancement Request Number 535 donnte@microsoft.com Bug in XSHd3 (rdvk# 591) [DT-XSH-159] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1263 Line: 38407 Section: siglongjmp Problem: As for longjmp, change... Action: "sigsetjmp" -> "siglongjmp". _____________________________________________________________________________ objection Enhancement Request Number 536 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 214) [tog-c99-xsh 188] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1265 Line: 38464-38465 Section: signal Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Change "Such a function is called a signal handler." To "An invocation of such a function because of a signal, or (recursively) of any further functions called by that invocation (other than functions in the standard library), is called a signal handler." [Ed note: Add to CH The DESCRIPTION is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 537 donnte@microsoft.com Bug in XSHd3 (rdvk# 592) [DT-XSH-160] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: please supply actual words/editing instructions, this current request is non responsive _____________________________________________________________________________ Page: 1265 Line: 38468 Section: signal Problem: Because signal() is a C function, there's an oddness here that should be addressed. Resetting the signal handler to SIG_DFL (or blocking being done) in the case of SIGILL is left implementation- defined by the C standard. POSIX has tacitly always left it that way as well. Action: Minimally, add rationale that it's being left as in the C standard on purpose. It's not obvious to me what's right (because getting an illegal instruction trap in an illegal instruction trap handler is a Very Bad Thing), but if there's a consensus amongst UNIX implementations, it might be addressable. _____________________________________________________________________________ objection Enhancement Request Number 538 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 215) [tog-c99-xsh 189] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1265 Line: 38476 Section: signal Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Add the following text after line 38476: "If the signal occurs as the result of calling the abort() or raise() function, the signal handler shall not call the raise function." _____________________________________________________________________________ objection Enhancement Request Number 539 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 216) [tog-c99-xsh 190] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1265 Line: 38477-38478 Section: signal Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Change "If the signal occurs other than as the result of calling abort(), kill (), or raise( ), the behavior is undefined if the signal handler calls any function in the standard library ..." To "If the signal occurs other than as the result of calling abort(), kill (), or raise( ), the behavior is undefined if the signal handler rrefers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or if the signal handler calls any function in the standard library ..." _____________________________________________________________________________ Objection Enhancement Request Number 540 donnte@microsoft.com Bug in XSHd3 (rdvk# 593) [DT-XSH-161] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1265 Line: 38479 Section: signal Problem: Referenced table is not there. Action: The reference should be to the table of functions in the Signal Concepts chapter. _____________________________________________________________________________ Editorial Enhancement Request Number 541 donnte@microsoft.com Bug in XSHd3 (rdvk# 594) [DT-XSH-162] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1266 Line: 38510 Section: signal Problem: Spelling Action: "honoured" -> "honored". _____________________________________________________________________________ objection Enhancement Request Number 542 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 73) [tog-c99-xsh 49] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1268 Line: 38577 Section: signbit Problem: Change required for alignment with C99 (ref C99 section 7.12.3.6). Action: Add the following entry after line 38577: NAME signbit - test sign SYNOPSIS #include int signbit(real-floating 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 signbit() macro shall determine whether the sign of its argument value is negative. RETURN VALUE The signbit() macro shall return a nonzero value if and only if the sign of its argument value is negative. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnan(), isnormal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. _____________________________________________________________________________ Comment Enhancement Request Number 543 donnte@microsoft.com Bug in XSHd3 (rdvk# 595) [DT-XSH-163] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1275 Line: 38721 Section: sigsetjmp Problem: This is correct. Action: _____________________________________________________________________________ editorial Enhancement Request Number 544 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 24) {drb-8} Tue, 18 Apr 2000 16:48:30 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1277 Line: 38812 Section: sigsuspend Problem: Although XSH6 has fixed the POSIX 1003.1-1996 bug claiming that sigsuspend() blocked "the process", (XSH6 correctly describes it as blocking the calling thread), there is one remaining "process" reference in the APPLICATION USAGE commentary that could cause some confusion, and should be fixed. On line 38812 it says "When the process has completed the critical section and needs to wait for the previously blocked signal(s) [...]". Action: The APPLICATION USAGE should be fixed to say "When the thread has completed the critical section and needs to wait for the previously blocked signal(s) [...]" (This doesn't address the fact that, in general, blocking signals is insufficient to enforce a critical section in a threaded process.) _____________________________________________________________________________ Editorial Enhancement Request Number 545 donnte@microsoft.com Bug in XSHd3 (rdvk# 596) [DT-XSH-164] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1279 Line: 38857 Section: sigtimedwait Problem: If the "released to queue other signals" is made (line 1481) change it here, as well. Action: Pending that change. _____________________________________________________________________________ objection Enhancement Request Number 546 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 89) [tog-c99-xsh 65] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1286 Line: 39047 Section: sin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Add after line 39047: float sinf(float x); long double sinl(long double x); [Ed note: Add to CH The sinf() and sinl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 547 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 90) [tog-c99-xsh 66] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The sin( ) function ..." To "The sin(), sinf() and sinl() functions ..." Same change on line 39064. _____________________________________________________________________________ Page: 1286 Line: 39052 Section: sin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Change "The sin( ) function ..." To "The sin family of functions ..." Same change on line 39064. _____________________________________________________________________________ objection Enhancement Request Number 548 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 91) [tog-c99-xsh 67] 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, sin( ) ..." To "Upon successful completion, the sin(), sinf() and sinl() functions ..." _____________________________________________________________________________ Page: 1286 Line: 39057 Section: sin Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Change "Upon successful completion, sin( ) ..." To "Upon successful completion, the sin family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 549 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 104) [tog-c99-xsh 80] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1288 Line: 39099 Section: sinh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Add after line 39099: float sinhf(float x); long double sinhl(long double x); [Ed note: Add to CH The sinhf() and sinhl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 550 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 105) [tog-c99-xsh 81] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The sinh( ) function ..." To "The sinh(), sinhf() and sinhl() functions ..." Same change on lines 39114 and 39116. _____________________________________________________________________________ Page: 1288 Line: 39104 Section: sinh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Change "The sinh( ) function ..." To "The sinh family of functions ..." Same change on lines 39114 and 39116. _____________________________________________________________________________ objection Enhancement Request Number 551 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 106) [tog-c99-xsh 82] 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, sinh( ) ..." To "Upon successful completion, the sinh(), sinhf() and sinhl() functions ..." _____________________________________________________________________________ Page: 1288 Line: 39108 Section: sinh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Change "Upon successful completion, sinh( ) ..." To "Upon successful completion, the sinh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 552 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 252) [tog-c99-xsh 226] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1297 Line: 39381-39382 Section: sprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.5-6). Action: Change "int snprintf(char *s, size_t n, const char * format, ...); int sprintf(char * s, const char * format, ...);" To "int snprintf(char * restrict s, size_t n, const char * restrict format, ...); int sprintf(char * restrict s, const char * restrict format, ...);" And remove XSI shading on snprintf(). [Ed note: Add to CH The snprintf() and sprintf() prototypes are updated for alignment with ISO/IEC 9899:1999 C . The XSI marking is removed from snprintf() and this is now in ISO/IEC 9899:1999.] _____________________________________________________________________________ objection Enhancement Request Number 553 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 155) [tog-c99-xsh 131] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1298 Line: 39389 Section: sqrt Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Add after line 39389: float sqrtf(float x); long double sqrtl(long double x); [Ed note: Add to CH The sqrtf() and sqrtl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 554 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 156) [tog-c99-xsh 132] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The sqrt( ) function ..." To "The sqrt(), sqrtf() and sqrtl() functions ..." Same change on lines 39402 and 39404. _____________________________________________________________________________ Page: 1298 Line: 39394 Section: sqrt Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "The sqrt( ) function ..." To "The sqrt family of functions ..." Same change on lines 39402 and 39404. _____________________________________________________________________________ objection Enhancement Request Number 555 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 157) [tog-c99-xsh 133] 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, sqrt( ) ..." To "Upon successful completion, the sqrt(), sqrtf() and sqrtl() functions ..." _____________________________________________________________________________ Page: 1298 Line: 39398 Section: sqrt Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "Upon successful completion, sqrt( ) ..." To "Upon successful completion, the sqrt family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 556 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 158) [tog-c99-xsh 133a] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: EMB ! unclear editing instructions. _____________________________________________________________________________ Page: 1298 Line: 39418 Section: sqrt Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "None." To "IEC 60559, unlike the Standard, requires sqrt(-0.) to return a negatively signed magnitude-zero result. This is an issue on implementations that support a negative floating zero. The Standard specifies that taking the square root of a negative number (in the mathematical sense of less than 0) is a domain error which requires the function to return an implementation-dependent value. This rule permits implementations to support either the IEC 60559 or vendor-specific floating point representations." _____________________________________________________________________________ objection Enhancement Request Number 557 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 253) [tog-c99-xsh 227] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1303 Line: 39461 Section: sscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.7). Action: Change "int sscanf(const char * s, const char * format, ...);" To "int sscanf(const char * restrict s, const char * restrict format, ...);" [Ed note: Add to CH The sscanf() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Comment Enhancement Request Number 558 donnte@microsoft.com Bug in XSHd3 (rdvk# 597) [DT-XSH-165] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add at 39662 stderr is expected to be open for reading and writing _____________________________________________________________________________ Page: 1309 Line: 39661 Section: stdin Problem: When the issue of the direction of stderr (both ways) gets resolved, it should be mention here, too. Action: Pending that decision. _____________________________________________________________________________ objection Enhancement Request Number 559 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 300) [tog-c99-xsh 274] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1312 Line: 39728 Section: strcat Problem: Change required for alignment with C99 (ref C99 section 7.21.3.1). Action: Change "char *strcat(char * s1, const char * s2);" To "char *strcat(char * restrict s1, const char * restrict s2);" [Ed note: Add to CH The strcat() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 560 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 298) [tog-c99-xsh 272] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1318 Line: 39934 Section: strcpy Problem: Change required for alignment with C99 (ref C99 section 7.21.2.3). Action: Change "char *strcpy(char * s1, const char * s2);" To "char *strcpy(char * restrict s1, const char * restrict s2);" [Ed note: Add to CH The strcpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 561 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 365) {drb-009} Tue, 25 Apr 2000 12:55:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept the change below, except that "int buflen" -> "size_t buflen" and CH should say The strerror_r() function is introduced in response to IEEE PASC interpretation 1003.1c #39. _____________________________________________________________________________ Page: 1322 Line: 40077 Section: strerror 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. In the response to POSIX 1003.1 interpretation request #39, the POSIX interpretations committee concurred that the functions getenv_r(), localeconv_r(), and strerror_r() had been inadvertently omitted from the standard, and recommended that they be added to a future revision. XSH6D3 should be that future revision. I am going to submit 3 separate bugs to cover this interpretation, one containing each of three proposed new man pages, rather than submit one annoyingly large bug containing all three. (The preceding header text will appear in all 3 for reference.) Action: Add strerror_r() to the strerror() man page: NAME strerror, strerror_r - get error message string SYNOPSIS #include char *strerror(int errnum); int strerror_r(int errnum, char *strerrbuf, int buflen); DESCRIPTION The strerror() function maps the error number in errnum to a locale-dependent error message string and returns a pointer thereto. The string pointed to must not be modified by the program, but may be overwritten by a subsequent call to strerror() or perror(). The contents of the error message strings returned by strerror() should be determined by the setting of the LC_MESSAGES category in the current locale. The implementation will behave as if no function defined in this specification calls strerror(). The strerror() function will not change the setting of errno if successful. Because no return value is reserved to indicate an error, an application wishing to check for error situations should set errno to 0, then call strerror(), then check errno. This interface need not be reentrant. The strerror_r() function maps the error number in errnum to a locale-dependent error message string and returns the string in the buffer pointed to by strerrbuf, with length buflen. RETURN VALUE Upon successful completion, strerror() returns a pointer to the generated message string. On error errno may be set, but no return value is reserved to indicate an error. Upon successful completion, strerror_r() returns 0. Otherwise, an error number is returned to indicate the error. ERRORS The strerror() and strerror_r functions may fail if: [EINVAL] The value of errnum is not a valid error number. The strerror_r() function may fail if: [ERANGE] Insufficient storage was supplied via strerrbuf and buflen to contain the generated message string. EXAMPLES None. APPLICATION USAGE None. FUTURE DIRECTIONS None. _____________________________________________________________________________ objection Enhancement Request Number 562 Sandra O Bug in XSHd3 (rdvk# 382) [compaq-smo-012] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1326 Line: 40250 Section: strfmon Problem: Inaccurate syntax for disabling currency symbol. Action: In the Conversion Specification column, change %(#5n to %(!#5n According to line 40168, the exclamation point is what suppresses the currency symbol. _____________________________________________________________________________ objection Enhancement Request Number 563 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 304) [tog-c99-xsh 278] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1328 Line: 40275-40276 Section: strftime Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Change "size_t strftime(char * s, size_t maxsize, const char * format, const struct tm * timptr); To "size_t strftime(char * restrict s, size_t maxsize, const char * restrict format, const struct tm * restrict timptr); [Ed note: Add to CH The strftime() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 564 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 305) [tog-c99-xsh 279] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1328 Line: 40283-40284 Section: strftime Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Change "A conversion specification consists of a '%' character and a terminating conversion character that determines the conversion specification's behavior." To "A conversion specification consists of a '%' character, possibly followed by an E or O modifier, and a terminating conversion character that determines the conversion specifications behavior." [Ed note: Add to CH The DESCRIPTION is extensively revised for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 565 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 306) [tog-c99-xsh 280] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1328-1329 Line: 40291-40333 Section: strftime Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Remove CX shading from the following consversion specifiers: %C, %D, %e, %h, %n, %r, %R, %t and %T. And add the following conversion specifiers to the table on lines 40291-40333: %F is equivalent to "%Y-%m-%d" (the ISO 8601 date format). %g is replaced by the last 2 digits of the week-based year (see below) as a decimal number (00-99). %G is replaced by the week-based year (see below) as a decimal number (e.g., 1997). %z is replaced by the offset from UTC in the ISO 8601 format "-0430" (meaning 4 hours 30 minutes behind UTC, west of Greenwich), or by no characters if no time zone is determinable. _____________________________________________________________________________ objection Enhancement Request Number 566 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 307) [tog-c99-xsh 281] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1330 Line: 40372 Section: strftime Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Add after line 40372: %g, %G, and %V give values according to the ISO 8601 week-based year. In this system, weeks begin on a Monday and week 1 of the year is the week that includes January 4th, which is also the week that includes the first Thursday of the year, and is also the first week that contains at least four days in the year. If the first Monday of January is the 2nd, 3rd, or 4th, the preceding days are part of the last week of the preceding year; thus, for Saturday 2nd January 1999, %G is replaced by 1998 and %V is replaced by 53.If December 29th, 30th, or 31st is a Monday, it and any following days are part of week 1 of the following year. Thus, for Tuesday 30th December 1997, %G is replaced by 1998 and %V is replaced by 01. If a conversion specifier is not one of the above, the behavior is undefined. _____________________________________________________________________________ objection Enhancement Request Number 567 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 308) [tog-c99-xsh 282] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1331 Line: 40403 Section: strftime Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Add after line 40403: In the "C" locale, the E and O modifiers are ignored and the replacement strings for the following specifiers are: %a the first three characters of %A. %A one of Sunday , Monday, ... , Saturday. %b the first three characters of %B. %B one of January , February, ... , December . %c equivalent to "%a %b %e %T %Y" . %p one of "AM" or "PM". %r equivalent to "%I:%M:%S %p" . %x equivalent to "%m/%d/%y" . %X equivalent to %T. %Z implementation-dependent. _____________________________________________________________________________ objection Enhancement Request Number 568 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 301) [tog-c99-xsh 275] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1336 Line: 40504 Section: strncat Problem: Change required for alignment with C99 (ref C99 section 7.21.3.2). Action: Change "char *strncat(char * s1, const char * s2, size_t n);" To "char *strncat(char * restrict s1, const char * restrict s2, size_t n);" [Ed note: Add to CH The strncat() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 569 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 299) [tog-c99-xsh 273] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1338 Line: 40580 Section: strncpy Problem: Change required for alignment with C99 (ref C99 section 7.21.2.4). Action: Change "char *strncpy(char * s1, const char * s2, size_t n);" To "char *strncpy(char * restrict s1, const char * restrict s2, size_t n);" [Ed note: Add to CH The strncpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 570 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 270) [tog-c99-xsh 244] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1348 Line: 40895 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "double strtod(const char * str, char ** endptr);" To "double strtod(const char * restrict nptr, char ** restrict endptr); float strtof(const char * restrict nptr, char ** restrict endptr); long double strtold(const char * restrict nptr, char ** restrict endptr); [Ed note: Add to CH The strtod() function is updated, and the strtof() and strtold() functions are added for alignment with ISO/IEC 9899:1999 C. ] _____________________________________________________________________________ objection Enhancement Request Number 571 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 271) [tog-c99-xsh 245] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1348 Line: 40900-40901 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "The strtod( ) function shall convert the initial portion of the string pointed to by str to type double representation. First it decomposes the input string into three parts: " To "The strtod(), strtof(), and strtold() functions shall convert the initial portion of the string pointed to by nptr to double, float, and long double representation, respectively. First, they decompose the input string into three parts: " _____________________________________________________________________________ objection Enhancement Request Number 572 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 272) [tog-c99-xsh 246] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1348 Line: 40903 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "2. A subject sequence interpreted as a floating-point constant:" To "2. A subject sequence interpreted as a floating-point constant or representing infinity or Nan." [Ed note: Add to CH The DESCRIPTION is extensively revised for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 573 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 273) [tog-c99-xsh 247] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the change. _____________________________________________________________________________ Page: 1348 Line: 40908-40914 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "The expected form of the subject sequence is an optional '+' or '-' sign, then a non-empty sequence of digits optionally containing a radix character, then an optional exponent part. An exponent part consists of e or E, followed by an optional sign, followed by one or more decimal digits. The subject sequence is defined as the longest initial subsequence of the input string, starting with the first non-white-space character that is of the expected form. The subject sequence is empty if the input string is empty or consists entirely of white-space characters, or if the first character that is not white-space is other than a sign, a digit, or a radix character. " To "The expected form of the subject sequence is an optional plus or minus sign, then one of the following: * a nonempty sequence of decimal digits optionally containing a radix character, then an optional exponent part. * a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a radix character, then an optional binary exponent part. * one of INF or INFINITY, ignoring case * one of NAN or NAN(n-char-sequence opt ), ignoring case in the NAN part, where: n-char-sequence: digit nondigit n-char-sequence digit n-char-sequence nondigit The subject sequence is defined as the longest initial subsequence of the input string, starting with the first non-white-space character, that is of the expected form. The subject sequence contains no characters if the input string is not of the expected form. _____________________________________________________________________________ objection Enhancement Request Number 574 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 274) [tog-c99-xsh 248] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1348 Line: 40915-40921 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "If the subject sequence has the expected form, the sequence starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the value resulting from the conversion is negated. A pointer to the final string is stored in the object pointed to by endptr, provided that endptr is not a null pointer." To "If the subject sequence has the expected form for a floating-point number, the sequence of characters starting with the first digit or the decimal-point character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears in a decimal floating point number, or if a binary exponent part does not appear in a hexadecimal floating point number, an exponent part of the appropriate type with value zero is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the sequence is interpreted as negated. A character sequence INF or INFINITY is interpreted as an infinity, if representable in the return type, else like a floating constant that is too large for the range of the return type. A character sequence NAN or NAN(n-char-sequence opt ), is interpreted as a quiet NaN, if supported in the return type, else like a subject sequence part that does not have the expected form; the meaning of the n-char sequences is implementation-dependent. A pointer to the final string is stored in the object pointed to by endptr, provided that endptr is not a null pointer. If the subject sequence has the hexadecimal form and FLT_RADIX is a power of 2, the value resulting from the conversion is correctly rounded." _____________________________________________________________________________ objection Enhancement Request Number 575 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 276) [tog-c99-xsh 250] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1349 Line: 40934-40937 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "Upon successful completion, strtod() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, HUGE_VAL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, 0 shall be returned and errno set to [ERANGE]." To "Upon successful completion, strtod(), strtof() and strtold() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, HUGE_VAL, HUGE_VALF or HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]." _____________________________________________________________________________ objection Enhancement Request Number 576 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 275) [tog-c99-xsh 249] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1349 Line: 40947 Section: strtod Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "None." To "If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction. If the subject sequence has the decimal form and at most DECIMAL_DIG (defined in ) significant digits, the result should be correctly rounded. If the subject sequence D has the decimal form and more than DECIMAL_DIG significant digits, consider the two bounding, adjacent decimal strings L and U, both having DECIMAL_DIG significant digits, such that the values of L, D, and U satisfy L <= D <= U. The result should be one of the (equal or adjacent) values that would be obtained by correctly rounding L and U according to the current rounding direction, with the extra stipulation that the error with respect to D should have a correct sign for the current rounding direction." _____________________________________________________________________________ objection Enhancement Request Number 577 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 62) [tog-c99-xsh 38] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1350 Line: 40976 Section: strtoimax Problem: Change required for alignment with C99 (ref C99 section 7.8.2.3). Action: Add the following entry after line 40976: NAME strtoimax, strtoumax - convert string to integer type SYNOPSIS #include intmax_t strtoimax(const char * restrict nptr, char ** restrict endptr, int base); uintmax_t strtoumax(const char * restrict nptr, char ** restrict endptr, int base); 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 strtoimax() and strtoumax() functions shall be equivalent to the strtol(), strtoll(), strtoul(), and strtoull() functions, except that the initial portion of the string shall be converted to intmax_t and uintmax_t representation, respectively. RETURN VALUE The strtoimax() and strtoumax() functions shall return the converted value, if any. If no conversion could be performed, zero shall be returned. If the correct value is outside the range of representable values, INTMAX_MAX, INTMAX_MIN,or UINTMAX_MAX shall be returned (according to the return type and sign of the value, if any), and errno set to [ERANGE}. ERRORS The strtoimax() and strtoumax() functions shall fail if: [ERANGE] The value to be returned is not representable. The strtoimax() and strtoumax() functions may fail if: [EINVAL] The value of base is not supported. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO strtol(), strtoll(), strtoul(), strtoull(), 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 578 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 303) [tog-c99-xsh 277] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1351 Line: 40981 Section: strtok Problem: Change required for alignment with C99 (ref C99 section 7.21.5.8). [Ed. strtok_r should probably be changed as well, but I have avoided adding the "restrict" type-qualifier to any none c99 functions. This area probably requires review by the working group.] Action: Change "char *strtok(char * s1, const char * s2);" To "char *strtok(char * restrict s1, const char * restrict s2);" [Ed note: Add to CH The strtok() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 579 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 277) [tog-c99-xsh 251] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1354 Line: 41089 Section: strtol Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "long int strtol(const char * str, char **endptr, int base);" To "long int strtol(const char * restrict str, char ** restrict endptr, int base);" long long int strtoll(const char * restrict str, char ** restrict endptr, int base);" [Ed note: Add to CH The strtol() prototype is updated, and the strtoll() function added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 580 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 278) [tog-c99-xsh 252] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1354 Line: 41094-41095 Section: strtol Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "The strtol() function shall convert the initial portion of the string pointed to by str to a type long int representation. First it decomposes the input string into three parts:" To "The strtol() and strtoll() functions shall convert the initial portion of the string pointed to by str to a type long int and long long int representation, respectively. First they decompose the input string into three parts:" _____________________________________________________________________________ objection Enhancement Request Number 581 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 279) [tog-c99-xsh 253] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1355 Line: 41130 Section: strtol Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Because 0, {LONG_MIN}, and {LONG_MAX} are returned on error ..." To "Because 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are returned on error ..." [Ed note: Add to CH This man page is extensively updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 582 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 280) [tog-c99-xsh 254] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1355 Line: 41134 Section: strtol Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Upon successful completion strtol() shall return ..." To "Upon successful completion strtol() and strtoll() shall return ..." _____________________________________________________________________________ objection Enhancement Request Number 583 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 281) [tog-c99-xsh 255] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1355 Line: 41136 Section: strtol Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "... {LONG_MAX} or {LONG_MIN} ..." To "... {LONG_MIN}, {LONG_MAX}, {LLONG_MIN} or {LLONG_MAX}, ..." _____________________________________________________________________________ objection Enhancement Request Number 584 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 282) [tog-c99-xsh 256] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1357 Line: 41183 Section: strtoul Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "long int strtoul(const char * str, char **endptr, int base);" To "long int strtoul(const char * restrict str, char ** restrict endptr, int base);" long long int strtoull(const char * restrict str, char ** restrict endptr, int base);" [Ed note: Add to CH The strtoul() prototype is updated, and the strtoull() function added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 585 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 283) [tog-c99-xsh 257] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1357 Line: 41188-41189 Section: strtoul Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "The strtoul() function shall convert the initial portion of the string pointed to by str to a type long int representation. First it decomposes the input string into three parts:" To "The strtoul() and strtoull() functions shall convert the initial portion of the string pointed to by str to a type long int and long long int representation, respectively. First they decompose the input string into three parts:" _____________________________________________________________________________ objection Enhancement Request Number 586 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 284) [tog-c99-xsh 258] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1358 Line: 41224 Section: strtoul Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Because 0, and {ULONG_MAX} are returned on error ..." To "Because 0, {ULONG_MAX} and {ULLONG_MAX} are returned on error ..." _____________________________________________________________________________ objection Enhancement Request Number 587 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 285) [tog-c99-xsh 259] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1358 Line: 41228 Section: strtoul Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Upon successful completion strtoul() shall return ..." To "Upon successful completion strtoul() and strtoull() shall return ..." [Ed note: Add to CH This man page is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 588 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 286) [tog-c99-xsh 260] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1358 Line: 41230 Section: strtoul Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "... {ULONG_MAX} ..." To "... {ULONG_MAX} or {ULLONG_MAX}, ..." _____________________________________________________________________________ objection Enhancement Request Number 589 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 302) [tog-c99-xsh 276] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1359 Line: 41265 Section: strxfrm Problem: Change required for alignment with C99 (ref C99 section 7.21.4.5). Action: Change "size_t strxfrm(char * s1, const char * s2, size_t n);" To "size_t strxfrm(char * restrict s1, const char * restrict s2, size_t n);" [Ed note: Add to CH The strxfrm() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ editorial Enhancement Request Number 590 Sandra O Bug in XSHd3 (rdvk# 383) [compaq-smo-013] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1359 Line: 41270-41271 Section: strxfrm Problem: Grammatical error Action: Change "The strxfrm() function shall transform the string...and places the resulting string..." to "The strxfrm() function shall transform the string...and place the resulting string..." _____________________________________________________________________________ objection Enhancement Request Number 591 Sandra O Bug in XSHd3 (rdvk# 384) [compaq-smo-014] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1363 Line: 41375 Section: swprintf Problem: The synopsis uses "s" to refer to a wide character string parameter. Action: Here and also at page 1364 line 41383 section swscanf objection page 1476 line 44791 section vfwprintf objection page 1478 line 44837 section vswprintf objection Change the synopsis for the wchar_t string parameters in the functions from "wchar_t *s" to wchar_t *ws". Most other wide character string parameters are called "ws", rather than "s" (see fgetws(), fputws(), wcscoll(), wcscpy(), etc.). Since most developers think of "s" as referring to a string of char's, it is misleading to use "s" here to refer to wchar_t's. _____________________________________________________________________________ Objection Enhancement Request Number 592 donnte@microsoft.com Bug in XSHd3 (rdvk# 598) [DT-XSH-166] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change 41397 to If the symlink( ) function fails for any reason other than EIO, any file named by path2 shall be unaffected. Make a similar change to rename(): add a similar para following p1116, l33896 If the rename() function fails for any reason other than EIO, any file named by new shall be unaffected. This is CX shaded. _____________________________________________________________________________ Page: 1365 Line: 41397 Section: symlink Problem: This statement, and the one about EIO, are generally not present, but would apply to most interfaces. However, they also conflict, in that the EIO condition could occur after the damage to the old link had been done. (That is, rename() should either have the same wording about these, and it's equally nonproductive to do so, because there's no way to fully recover from an EIO reported back to the user.) Action: Delete both. _____________________________________________________________________________ editorial Enhancement Request Number 593 al.simons@compaq.com Bug in XSHd3 (rdvk# 398) {compaq-aks-007} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1365 Line: 41413 Section: symlink Problem: Referenced argument doesn't exist in the function prototype: pname. I think that this comes from a cut/paste error. Action: Change "pname" to "path1". _____________________________________________________________________________ editorial Enhancement Request Number 594 drepper@redhat.com Bug in XSHd3 (rdvk# 17) {ud-26} Thu, 13 Apr 2000 02:13:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1369 Line: 41552 Section: sysconf() Problem: This line can be removed. The entry is a duplication of the second column value of the previous line. Action: Remove the line. _____________________________________________________________________________ Editorial Enhancement Request Number 595 donnte@microsoft.com Bug in XSHd3 (rdvk# 599) [DT-XSH-167] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1371 Line: 41627 Section: sysconf Problem: Ugly page break. Action: Fix. _____________________________________________________________________________ objection Enhancement Request Number 596 ajosey@opengroup.org Bug in XSHd3 (rdvk# 410) {c99-sysconf-1} Sun, 30 Apr 2000 08:38:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1372 Line: 41631 Section: sysconf Problem: As part of the introduction of the new c99 utility, we need to mark obsolete (LEGACY) the macros associated with the data models used by c89 , and introduce new macros for the data models used by c99. (see also the changes to create the c99 man page XCU c99-c99-1) Action: Copy lines 41631-41634, renaming occurrences of _XBS5_ to _POSIX_V6, and _SC_XBS5_ to _SC_V6_ Mark the existing lines as LEGACY (in parentheses). Update the Change History The macros associated with the c89 programming models are marked LEGACY and new equivalent macros associated with c99 are introduced. _____________________________________________________________________________ comment Enhancement Request Number 597 prindle@voicenet.com Bug in XSHd3 (rdvk# 664) [prindle.xsh-34] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Cathy has markup these come from 1003.2d _____________________________________________________________________________ Page: 1375 Line: 41788 Section: sysconf() Problem: Some introductory text here is missing. The symbols from 41788 onward are not introduced by amendment 1003.1j, but more likely by by 1003.2b (?). Action: Put these symbols under the appropriate introductory paragraph. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 598 donnte@microsoft.com Bug in XSHd3 (rdvk# 600) [DT-XSH-168] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The "IEEE"s come from a macro that will be changed as appropriate when IEEE and/or ISO adopt the standard. XCU support is required for conformance to this revision of the combined standards. _____________________________________________________________________________ Page: 1379 Line: 41892 Section: system Problem: Both here and at 41894, we're now talking about something that is defined in this standard. Action: Change the first sentence at 41887 to: "The system interfaces volume of this standard adds two additional levels:" On 41892: delete IEEE... to the end of the paragraph. On 41894: Replace "Finally,...requires" with "In addition, if the Commands and Utilities option is implemented, it..." _____________________________________________________________________________ Editorial Enhancement Request Number 599 donnte@microsoft.com Bug in XSHd3 (rdvk# 601) [DT-XSH-169] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "A system have" -> "A system must have". _____________________________________________________________________________ Page: 1379 Line: 41898 Section: system Problem: missing word. Action: "A system have" -> "A system must have". Actually, this paragraph is slightly wrong, because it's assuming that C&U is implemented (which was true for the .2 text from which this came). Rewrite of the paragraph (and to clean up some other junk). Note that if the Commands and Utilities option is implemented, system(NULL) is required to return non-zero, indicating that there is a command language interpreter. In effect, this standard is profiling the C standard in this regard, requiring that only one of the permissible behaviors is actually allowed in an implementation conforming to _this_ standard. (Note also... the text at 41811 about fork and exec should be shaded and marked CX... fork and exec are not in the C standard.) (Note again: 41814 should probably be tagged "CX CU", except there isn't a CU option after all...) ...help... I feel like I'm falling down a rabbit#####rat hole. This whole page needs a complete rewrite to reflect more accurately the consequences of merging .1, .2 and C. I don't have time right now. (Ask the editors to do it, and flag it as particularly needing review next time around.) _____________________________________________________________________________ objection Enhancement Request Number 600 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 92) [tog-c99-xsh 68] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1382 Line: 42008 Section: tan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Add after line 42008: float tanf(float x); long double tanl(long double x); [Ed note: Add to CH The tanf() and tanl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 601 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 93) [tog-c99-xsh 69] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The tan( ) function ..." To "The tan(), tanf() and tanl() functions ..." Same change on lines 42027 and 42029. _____________________________________________________________________________ Page: 1382 Line: 42013 Section: tan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Change "The tan( ) function ..." To "The tan family of functions ..." Same change on lines 42027 and 42029. _____________________________________________________________________________ objection Enhancement Request Number 602 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 94) [tog-c99-xsh 70] 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, tan( ) ..." To "Upon successful completion, the tan(), tanf() and tanl() functions ..." _____________________________________________________________________________ Page: 1382 Line: 42018 Section: tan Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Change "Upon successful completion, tan( ) ..." To "Upon successful completion, the tan family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 603 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 107) [tog-c99-xsh 83] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1384 Line: 42064 Section: tanh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Add after line 42064: float tanhf(float x); long double tanhl(long double x); [Ed note: Add to CH The tanhf() and tanhl() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 604 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 108) [tog-c99-xsh 84] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The tanh( ) function ..." To "The tanh(), tanhf() and tanhl() functions ..." Same change on line 42078. _____________________________________________________________________________ Page: 1384 Line: 42069 Section: tanh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Change "The tanh( ) function ..." To "The tanh family of functions ..." Same change on line 42078. _____________________________________________________________________________ objection Enhancement Request Number 605 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 109) [tog-c99-xsh 85] 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, tanh( ) ..." To "Upon successful completion, the tanh(), tanhf() and tanhl() functions ..." _____________________________________________________________________________ Page: 1384 Line: 42073 Section: tanh Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Change "Upon successful completion, tanh( ) ..." To "Upon successful completion, the tanh family of functions ..." _____________________________________________________________________________ objection Enhancement Request Number 606 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 170) [tog-c99-xsh 144] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 1408 Line: 42746 Section: tgamma Problem: Change required for alignment with C99 (ref C99 section 7.12.8.4). Action: Add the following entry after line 42746: NAME tgamma - compute gamma function SYNOPSIS #include double tgamma(double x); float tgammaf(float x); long double tgammal(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 tgamma() functions shall compute the gamma function 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 tgamma() functions shall return Gamma(x). If x is NaN, NaN shall be returned and errno may be set to [EDOM]. If x is a negative integer, or if the result cannot be represented when x is 0, either HUGE_VAL or NaN shall be returned and errno shall be set to [EDOM]. If the magnitude of x is too large or too small, 1HUGE_VAL shall be returned and errno shall be set too [ERANGE] ERRORS The tgamma() functions shall fail if: [EDOM] The value of x is negative or the result cannot be represented when x is zero. [ERANGE] The magnitude of x is too large or too small. The tgamma() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In many other standards, the meaning of gamma has changed over the years. Originally, it computed the logarithm of the absolute value of the mathematical gamma function, with an external int, signgam, being set to the sign of the gamma function. Then gamma was replaced with lgamma, and gamma was slated to be withdrawn. About that time, NCEG changed gamma to compute the mathematical gamma function, and that is what was adopted into C9X CD1; but it appears that the old meaning of gamma has not yet been withdrawn, so there would have been a conflict between C9X and current industry practice. C9X therefore changed the name in the FCD to tgamma, meaning true gamma, to avoid this conflict. 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. _____________________________________________________________________________ editorial Enhancement Request Number 607 tomp@zk3.dec.com Bug in XSHd3 (rdvk# 672) {compaq-tap-001} Mon, 1 May 2000 08:14:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1410 Line: 42813 Section: time Problem: Missing word. Action: Add the word "alternate" between the words "an" and "function". _____________________________________________________________________________ objection Enhancement Request Number 608 prindle@voicenet.com Bug in XSHd3 (rdvk# 666) [prindle.xsh-36] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1412 Line: 42854 Section: timer_create() Problem: The wording "If...supported, all implementations shall..." is nonsense. The word "all" causes the problem. Action: Delete the word "all". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 609 prindle@voicenet.com Bug in XSHd3 (rdvk# 671) [prindle.xsh-41] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1413 Line: 42876-42878 Section: timer_create() Problem: This error should be shaded and margin marked with CPT|TCT. Action: Shade and mark CPT|TCT. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 610 donnte@microsoft.com Bug in XSHd3 (rdvk# 602) [DT-XSH-170] 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. The submitter is recommended to file an interp request if he still believes this problem is relevant. _____________________________________________________________________________ Page: 1416 Line: 43010 Section: timer_getoverrun Problem: (This was left open last time, and I see no resolution.) Meaning unclear (possible typo?). should "a timer on pending expiration" be "a timer with pending expiration"? Action: As above, or clarify if I didn't guess right. _____________________________________________________________________________ objection Enhancement Request Number 611 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 220) [tog-c99-xsh 194] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1424 Line: 43221 Section: tmpfile Problem: Change required for alignment with C99 (ref C99 section 7.19.4.3). Action: Change "None." To "It should be possible to open at least TMP_MAX temporary files during the lifetime of the program (this limit may be shared with tmpnam) and there should be no limit on the number simultaneously open other than this limit and any limit on the number of open files (FOPEN_MAX)." [Ed note: Add to CH The APPLICATION USAGE section is added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 612 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 221) [tog-c99-xsh 195] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1425 Line: 43259-43260 Section: tmpnam Problem: Change required for alignment with C99 (ref C99 section 7.19.4.4). Action: Change "The tmpnam( ) function shall generate a string that is a valid file name and that is not the same as the name of an existing file." To "The tmpnam( ) function shall generate a string that is a valid file name and that is not the same as the name of an existing file. The function is potentially capable of generating TMP_MAX different strings, but any or all of them may already be in use by existing files and thus not be suitable return values." [Ed note: Add to CH The DESCRIPTION is expanded for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 613 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 222) [tog-c99-xsh 196] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1425 Line: 43270 Section: tmpnam Problem: Change required for alignment with C99 (ref C99 section 7.19.4.6). Action: Add the following text after line 43270: If no suitable string can be generated, the tmpnam function shall return a null pointer. _____________________________________________________________________________ Objection Enhancement Request Number 614 donnte@microsoft.com Bug in XSHd3 (rdvk# 603) [DT-XSH-171] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This function did not get selected for legacy - out of scope. _____________________________________________________________________________ Page: 1427 Line: 43307 Section: toascii Problem: As noted (and rejected) last time, this name is misleading because it could (reasonably) be interpreted (if the reader doesn't read carefully) as a dumb translator from the current character set to ASCII. I'd prefer to see it deleted (particularly since the equivalent C is actually one character shorter and far more obvious that it's doing bit manipulation). Action: 1) Delete, or if not... 2) Mark legacy and add to Application Usage: "This function is retained for backwards compatibility; new applications are suggested to use "c&0x7f" directly, as it is clearer that bit manipulation rather than a true lookup is involved." _____________________________________________________________________________ objection Enhancement Request Number 615 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 186) [tog-c99-xsh 160] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: LTF _____________________________________________________________________________ Page: 1432 Line: 43530 Section: trunc Problem: Change required for alignment with C99 (ref C99 section 7.12.9.8). Action: Add the following entry after line 34290: NAME trunc - round to truncated integer value SYNOPSIS #include double trunc(double x); float truncf(float x); long double truncl(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 trunc() functions shall round their argument to the integer value, in floating format, nearest to but no larger in magnitude than the argument. 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 trunc() functions shall return the truncated integer value. If x is 1Inf, the trunc() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The round() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. 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 616 donnte@microsoft.com Bug in XSHd3 (rdvk# 604) [DT-XSH-172] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The Base WG ruled that it should increase the file size (and require that as an XSI extension to ftruncate). The changes have been made. _____________________________________________________________________________ Page: 1433 Line: 43538 Section: truncate Problem: In the next paragraph it's unspecified whether files are extended, so at this point it's wrong. Action: Replace with: The truncate() function shall cause the regular file named by path to have a size which does not exceed length bytes. _____________________________________________________________________________ editorial Enhancement Request Number 617 al.simons@compaq.com Bug in XSHd3 (rdvk# 396) {compaq-aks-008} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1433 Line: 43547 Section: truncate Problem: Wording left over from ftruncate cut/paste is no longer meaningful. The phrase, "and if the file is a regular file," should be removed because truncate only operates on regular files, unlike ftruncate. Action: Remove "and if the file is a regular file,". _____________________________________________________________________________ editorial Enhancement Request Number 618 prindle@voicenet.com Bug in XSHd3 (rdvk# 665) [prindle.xsh-35] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1435 Line: 43595 Section: tsearch() Problem: This page seems to defy the convention that a page that contains multiple interfaces should appear in the place where the alphabetically first interface name would appear, and all other functions backward reference to that place. Here tsearch() is third. Action: Move this page to the position of tdelete(), and make tfind(), tsearch(), and twalk() back reference pages. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 619 al.simons@compaq.com Bug in XSHd3 (rdvk# 399) {compaq-aks-009} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1439 Line: 43777,43780 Section: ttyname Problem: The rationale states that the terminology was changed from "terminal device" to "terminal" to avoid use of an undefined term. This change needs completing, and also we should use "terminal" instead of "tty" for the same reason. Action: at line 43777 change "terminal device" to "terminal" at line 43780 change "tty" to "terminal" _____________________________________________________________________________ objection Enhancement Request Number 620 tomp@zk3.dec.com Bug in XSHd3 (rdvk# 675) {compaq-tap-002} Mon, 1 May 2000 08:14:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add 2 to p1442 l43832 _____________________________________________________________________________ Page: 1443 Line: 43841 Section: tzset Problem: The declaration of tzname specifies an array size of [2]. This should be empty (ie: tzname[] instead of tzname[2]). The tzname[2] declaration is inconsistent with current & historical implementations, as well as its counterpart declaration in the tzname section of this same draft. Action: Change "tzname[2]" to "tzname[]". _____________________________________________________________________________ Objection Enhancement Request Number 621 donnte@microsoft.com Bug in XSHd3 (rdvk# 605) [DT-XSH-173] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: italic cw, (cathy has markup) _____________________________________________________________________________ Page: 1443 Line: 43848 Section: tzset Problem: In this case, std and dst are referring to meta variables (not the literal strings) and should NOT appear in CW font. (Probably should be unquoted.) Action: Not in CW (at least). _____________________________________________________________________________ objection Enhancement Request Number 622 prindle@voicenet.com Bug in XSHd3 (rdvk# 668) [prindle.xsh-38] Mon, 01 May 2000 16:24:44 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This was fixed in an action post meeting and the changes actioned. _____________________________________________________________________________ Page: 1434 Line: 53571 Section: truncate() Problem: The error (necessitated by P1003.1a): [ELOOP] More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the path argument. is missing for the regular file named by path. This is potentially a global problem. Since P1003.1a amended 1003.1 and not XSH, it would not have shown this error being added to XSI or C unique functions not in POSIX.1. Action: Add this error here, and in all XSI and C functions which take a pathname or filename argument that is required to be in the filesystem namespace. Note that functions such as mq_open(), sem_open(), shm_open() which do not require the object named be in the filesystem namespace (but allow it), do not specify ELOOP errors, either the mandatory one or the optional one; so if any XSI functions fall in this category, do not add this in that case. Food for thought: if a named semaphore, for example, IS implemented as a special file in the filesystem, are symbolic links to it valid? Should the standard be addressing the potential symlink errors in the context of these special namespaces that may in fact be the filesystem namespace? ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 623 donnte@microsoft.com Bug in XSHd3 (rdvk# 606) [DT-XSH-174] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: did not make the new legacy list _____________________________________________________________________________ Page: 1445 Line: 43922 Section: ualarm Problem: A good case for legacy. Action: Make legacy. _____________________________________________________________________________ objection Enhancement Request Number 624 al.simons@compaq.com Bug in XSHd3 (rdvk# 401) {compaq-aks-002} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1447 Line: 43955-43956 Section: ulimit Problem: The description of the UL_SETFSIZE return value is unclear, and can be read to cause returning a value that is 512 times too large. Action: Reword the description of UL_SETFSIZE by reordering the 3rd and 4th sentences, and using the wording from UL_GETFSIZE for the return value. To make the paragraph read better, some collapsing can take place as well. The resulting paragraph reads: "UL_SETFSIZE Set the file size limit for output operations of the process to the value of the second argument, taken as a long int, multiplied by 512. If the result would overflow an rlim_t, the actual value set is unspecified. Any process may decrease its own limit, but only a process with appropriate privileges may increase the limit. The return value shall be the integer part of the new file size limit divided by 512." While I think this wording is clearer than that existing, my objection extends only to not making clear that the return value is the new file size limit, DIVIDED BY 512. The rest of this is editorial. _____________________________________________________________________________ Objection Enhancement Request Number 625 donnte@microsoft.com Bug in XSHd3 (rdvk# 607) [DT-XSH-175] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: did not make the new legacy list _____________________________________________________________________________ Page: 1447 Line: 43973 Section: ulimit Problem: Mark legacy. Action: Mark legacy, add: Applications are suggested to use setrlimit() to achieve this functionality. _____________________________________________________________________________ Objection Enhancement Request Number 626 donnte@microsoft.com Bug in XSHd3 (rdvk# 608) [DT-XSH-176] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: this is the approved ISO / IEEE terminology _____________________________________________________________________________ Page: 1457 Line: 44212 Section: unlink Problem: "application shall ensure" is wrong, again. Action: Restore .1 text (simply "shall"). _____________________________________________________________________________ Comment Enhancement Request Number 627 donnte@microsoft.com Bug in XSHd3 (rdvk# 609) [DT-XSH-177] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: pseudo terminal is defined in XBD _____________________________________________________________________________ Page: 1462 Line: 44410 Section: unlockpt Problem: PTYs are not defined even as an XSI extension in this document (or it's well buried). Action: Drop this leftover (or define PTYs, which isn't a bad idea, but may be out of scope.) Also delete ptsname() and unlockpt(). _____________________________________________________________________________ Comment Enhancement Request Number 628 donnte@microsoft.com Bug in XSHd3 (rdvk# 610) [DT-XSH-178] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: did not make the new legacy list _____________________________________________________________________________ Page: 1464 Line: 44449 Section: usleep Problem: Consider for legacy, given the number of slightly different timer interfaces. Action: Legacy. _____________________________________________________________________________ objection Enhancement Request Number 629 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 218) [tog-c99-xsh 192] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1471 Line: 44674 Section: va_arg Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Change "va_arg, va_end, va_start handle variable argument list" To "va_arg, va_copy, va_end, va_start handle variable argument list" _____________________________________________________________________________ objection Enhancement Request Number 630 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 219) [tog-c99-xsh 193] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1471 Line: 44677 Section: va_arg Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Add the following after line 44677: void va_copy(va_list dest, va_list src); [Ed note: Add to CH The va_copy() function is added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 631 donnte@microsoft.com Bug in XSHd3 (rdvk# 611) [DT-XSH-179] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See austin_34r1 _____________________________________________________________________________ Page: 1472 Line: 44692 Section: vfork Problem: (This was left open last time, and I see no resolution.) Does that include dup/dup2, e.g.? (Does "function" mean user function?) This constraint does not appear on the man pages for the other vfork() implementations I investigated, and it would make it difficult to remap file descriptors after the vfork() and before the exec(). (In fact a posix_spawn() implemented using vfork() probably is not possible as a conforming application, given this wording.) The discussion of signals at 44723 makes it even weirder. Action: 1) Consider simply deleting vfork. The caveats are even worse here than they are in the real world. 2) If not, either allow system calls such as dup/dup2 (those that were discussed during the development of posix_spawn() provides a good list) or explain what the additional conditions that require this might be. (I don't immediately see any reason why a call to dup() would do any more damage than a call to exec() to the parent.) _____________________________________________________________________________ objection Enhancement Request Number 632 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 254) [tog-c99-xsh 228] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1474 Line: 44741-44744 Section: vfprintf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.8). Action: Change "int vfprintf(FILE * stream, const char * format, va_list ap); int vprintf(const char * format, va_list ap); int vsnprintf(char * s, size_t n, const char * format, va_list ap); int vsprintf(char * s, const char * format, va_list ap);" To "int vfprintf(FILE * restrict stream, const char * restrict format, va_list ap); int vprintf(const char * restrict format, va_list ap); int vsnprintf(char * restrict s, size_t n, const char * restrict format, va_list ap); int vsprintf(char * restrict s, const char * restrict format, va_list ap);" [Ed note: Add to CH The vfprintf(), vprintf(), vsnprintf() and vsprintf() functions are updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 633 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 255) [tog-c99-xsh 229] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1475 Line: 44783 Section: vfscanf Problem: Change required for alignment with C99 (ref C99 section 7.19.6.9). Action: Add the following entry after line 44783 NAME vfscanf - format input of a stdarg list SYNOPSIS #include #include int vfscanf(FILE * restrict stream, const char * restrict format, va_list arg); int vscanf(const char * restrict format, va_list arg); int vsscanf(const char * restrict s, const char * restrict format, va_list arg); 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 The vscanf(), vfscanf (), and vsscanf( ) functions shall be the same as scanf(), fscanf (), and sscanf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . These functions do not invoke the va_end macro. As these functions invoke the va_arg macro, the value of ap after the return is indeterminate. RETURN VALUE Refer to fscanf(). ERRORS Referto fscanf(). EXAMPLES None. APPLICATION USAGE Applications using these functions should call va_end(ap) afterwards to clean up. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fscanf ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , . _____________________________________________________________________________ objection Enhancement Request Number 634 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 326) [tog-c99-xsh 300] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1476 Line: 44790-44793 Section: vfwprintf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.5). Action: Change "int vfwprintf(FILE * stream, const wchar_t * format, va_list arg); int vswprintf(wchar_t * s, size_t n, const wchar_t * format, va_list arg); int vwprintf(const wchar_t * format, va_list arg);" To "int vfwprintf(FILE * restrict stream, const wchar_t * restrict format, va_list arg); int vswprintf(wchar_t * restrict s, size_t n, const wchar_t * restrict format, va_list arg); int vwprintf(const wchar_t * restrict format, va_list arg); [Ed note: Add to CH The vfwprintf(), vswprintf(), vwprintf() prototypes are updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 635 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 327) [tog-c99-xsh 301] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1476 Line: 44820 Section: vfwscanf Problem: Change required for alignment with C99 (ref C99 section 7.23.2.6). Action: Add the following entry after line 44820 NAME vfwscanf - wide-character formattted input of a stdarg list SYNOPSIS #include #include #include int vfwscanf(FILE * restrict stream, const wchar_t * restrict format, va_list arg); int vswscanf(const wchar_t * restrict s, const wchar_t * restrict format, va_list arg); int vwscanf(const wchar_t * restrict format, va_list arg); 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 The vfwscanf(), vswscanf (), and vwscanf( ) functions shall be the same as fwscanf(), swscanf (), and wscanf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . These functions do not invoke the va_end macro. As these functions invoke the va_arg macro, the value of ap after the return is indeterminate. RETURN VALUE Refer to fwscanf(). ERRORS Referto fwscanf(). EXAMPLES None. APPLICATION USAGE Applications using these functions should call va_end(ap) afterwards to clean up. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fwscanf ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , . _____________________________________________________________________________ editorial Enhancement Request Number 636 Sandra O Bug in XSHd3 (rdvk# 385) [compaq-smo-015] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1478 Line: 44841 Section: vswprintf Problem: Incorrect function name. Action: The Description says "Refer to vswprintf()" but it should say "Refer to vfwprintf()." _____________________________________________________________________________ editorial Enhancement Request Number 637 al.simons@compaq.com Bug in XSHd3 (rdvk# 400) {compaq-aks-001} Tue, 25 Apr 2000 10:42:25 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Reword the sentence to read (in its entirety) "The status of any child processes specified by pid that are stopped, and whose status has not yet been reported since they stopped, shall also be reported to the requesting process." _____________________________________________________________________________ Page: 1479 Line: 44880-44882 Section: wait Problem: Sentence contains typos. The sentence contains the phrase "...since they stopped, is shall also be reported..." Action: Reword the sentence to read (in its entirety) "The status of any child processes specified by pid that are stopped, and whose status has not yet been reported since they are stopped, shall also be reported to the requesting process." _____________________________________________________________________________ Editorial Enhancement Request Number 638 donnte@microsoft.com Bug in XSHd3 (rdvk# 612) [DT-XSH-180] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1479 Line: 44881 Section: wait Problem: "is shall also" is not English. Action: -> "shall also". _____________________________________________________________________________ objection Enhancement Request Number 639 David.Butenhof@compaq.com Bug in XSHd3 (rdvk# 417) {drb-14} Mon, 1 May 2000 18:00:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1480 Line: 44890 Section: wait 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. POSIX 1003.1 Interpretation #49 points out an error in merging the text of the 1003.1c amendment into the base standard. The description of the wait and waitpid functions says "If and only if the status returned is from a terminated child process that returned 0 from main() or passed 0 as the status argument to _exit() or exit(), the value stored at the location pointed to by stat_loc shall be 0." This is incorrect, as POSIX specifies that a process shall also return the value 0 after the last thread has been terminated. Although the pthread_exit() page says "The behavior shall be as if the implementation called exit() with a zero argument at thread termination time", the description in wait will mislead anyone who hasn't read both places. Action: The sentence in wait should read: The value stored at the location pointed to by stat_lock shall be 0 if and only if the status returned is from a terminated child process that terminated by one of the following means: 1) The process returned 0 from main() 2) The process called _exit() or exit() with a status argument of 0 3) The process was terminated because the last thread in the process terminated. (I won't insist that the various conditions be broken out into a list, or necessarily into three items; however that seems to make the text much easier to read.) [Ed note: Add to CH The DESCRIPTION is updated for IEEE PASC Interpretation 1003.1c #49] _____________________________________________________________________________ objection Enhancement Request Number 640 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 357) [tog-c99-xsh 331] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1489 Line: 45192 Section: wcrtomb Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.3). Action: Change "size_t wcrtomb(char * s, wchar_t wc, mbstate_t * ps);" To "size_t wcrtomb(char * restrict s, wchar_t wc, mbstate_t * restrict ps);" [Ed note: Add to CH The wcrtomb() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ editorial Enhancement Request Number 641 Sandra O Bug in XSHd3 (rdvk# 386) [compaq-smo-016] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1489 Line: 45219 Section: wcrtomb Problem: Typo reference to size_t. Action: Change "(size_td)-1" to "(size_t)-1". _____________________________________________________________________________ objection Enhancement Request Number 642 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 348) [tog-c99-xsh 322] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1491 Line: 45245 Section: wcscat Problem: Change required for alignment with C99 (ref C99 section 7.24.4.3.1). Action: Change "wchar_t *wcscat(wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcscat(wchar_t * restrict ws1, const wchar_t * restrict ws2);" [Ed note: Add to CH The wcscat() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 643 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 345) [tog-c99-xsh 319] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1495 Line: 45386 Section: wcscpy Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.1). Action: Change "wchar_t *wcscpy(wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcscpy(wchar_t * restrict ws1, const wchar_t * restrict ws2);" [Ed note: Add to CH The wcscpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ comment Enhancement Request Number 644 Sandra O Bug in XSHd3 (rdvk# 387) [compaq-smo-017] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1495 Line: 45401-45402 Section: wcscpy Problem: Unhelpful Application Usage information. Action: Here and also at page 1501 line 45604-45605 section wscncpy comment Delete the lines that say "Wide-character code movement is performed differently on different implementations. Thus overlapping moves may yield surprises." While it is true that such movement is implementation- dependent, this information is equally applicable to most of the wcs*() functions; it is not specific to wcscpy() and so should not be called out here. _____________________________________________________________________________ objection Enhancement Request Number 645 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 353) [tog-c99-xsh 327] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1497 Line: 45449-45450 Section: wcsftime Problem: Change required for alignment with C99 (ref C99 section 7.24.5.1). Action: Change "size_t wcsftime(wchar_t * wcs, size_t maxsize, const wchar_t * format, const struct tm * timptr); " To "size_t wcsftime(wchar_t * restrict wcs, size_t maxsize, const wchar_t * restrict format, const struct tm * restrict timptr); " [Ed note: Add to CH The wcsftime() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ editorial Enhancement Request Number 646 Sandra O Bug in XSHd3 (rdvk# 388) [compaq-smo-018] Thu, 27 Apr 2000 11:25:10 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1497 Line: 45486 Section: wcsftime Problem: Typo in word "argument." Action: Fix typo so that "rgument" becomes "argument". _____________________________________________________________________________ objection Enhancement Request Number 647 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 349) [tog-c99-xsh 323] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1499 Line: 45520 Section: wcsncat Problem: Change required for alignment with C99 (ref C99 section 7.24.4.3.2). Action: Change "wchar_t *wcsncat(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wcsncat(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" [Ed note: Add to CH The wcsncat() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 648 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 346) [tog-c99-xsh 320] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1501 Line: 45585 Section: wcsncpy Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.2). Action: Change "wchar_t *wcsncpy(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wcsncpy(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" [Ed note: Add to CH The wcsncpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 649 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 359) [tog-c99-xsh 333] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1504 Line: 45683-45684 Section: wcsrtombs Problem: Change required for alignment with C99 (ref C99 section 7.24.6.4.2). Action: Change "size_t wcsrtombs(char * dst, const wchar_t ** src, size_t len, mbstate_t * ps);" To "size_t wcsrtombs(char * restrict dst, const wchar_t ** restrict src, size_t len, mbstate_t * restrict ps);" [Ed note: Add to CH The wcsrtombs() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 650 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 351) [tog-c99-xsh 325] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1507 Line: 45777 Section: wcsstr Problem: Change required for alignment with C99 (ref C99 section 7.24.4.5.6). Action: Change "wchar_t *wcsstr(const wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcsstr(const wchar_t * restrict ws1, const wchar_t * restrict ws2);" [Ed note: Add to CH The wcsstr() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 651 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 330) [tog-c99-xsh 304] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1508 Line: 45808 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "double wcstod(const wchar_t * nptr, wchar_t ** endptr);" To "double wcstod(const wchar_t * restrict nptr, wchar_t ** restrict endptr); float wcstof(const wchar_t * restrict nptr, wchar_t ** restrict endptr); long double wcstold(const wchar_t * restrict nptr, wchar_t ** restrict endptr);" [Ed note: Add to CH The wcstod() prototype is updated , and the wcstof() and wcstold() functions are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 652 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 331) [tog-c99-xsh 305] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1508 Line: 45813-45814 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "The wcstod( ) function shall convert the initial portion of the string pointed to by nptr to type double representation. First it decomposes the input wide-character string into three parts: " To "The wcstod(), wcstof(), and wcstold() functions shall convert the initial portion of the wide string pointed to by nptr to double, float, and long double representation, respectively. First, they decompose the input string into three parts: " _____________________________________________________________________________ objection Enhancement Request Number 653 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 332) [tog-c99-xsh 306] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1508 Line: 45818 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "2. A subject sequence interpreted as a floating-point constant:" To "2. A subject sequence interpreted as a floating-point constant or representing infinity or Nan." _____________________________________________________________________________ objection Enhancement Request Number 654 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 333) [tog-c99-xsh 307] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1508 Line: 45823-45830 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "The expected form of the subject sequence is an optional '+' or '-' sign, then a non-empty sequence of digits optionally containing a radix character, then an optional exponent part. An exponent part consists of 'e' or 'E', followed by an optional sign, followed by one or more decimal digits. The subject sequence is defined as the longest initial subsequence of the input wide-character string, starting with the first non-white-space wide-character code, that is of the expected form. The subject sequence contains no wide-character codes if the input wide-character string is empty or consists entirely of white-space wide-character codes, or if the first wide-character code that is not white space other than a sign, a digit, or a radix character. To "The expected form of the subject sequence is an optional plus or minus sign, then one of the following: * a nonempty sequence of decimal digits optionally containing a radix character, then an optional exponent part. * a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a radix character, then an optional binary exponent part. * one of INF or INFINITY, or any other wide string equivalent except for case. * one of NAN or NAN(n-wchar-sequence opt ), or any other wide string equivalent except for case in the NAN part, where: n-wchar-sequence: digit nondigit n-wchar-sequence digit n-wchar-sequence nondigit The subject sequence is defined as the longest initial subsequence of the input wide string, starting with the first non-white-space wide character, that is of the expected form. The subject sequence contains no wide characters if the input wide string is not of the expected form. [Ed note: Add to CH This man page is extensively updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 655 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 334) [tog-c99-xsh 308] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1508 Line: 45831-45837 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "If the subject sequence has the expected form, the sequence of wide-character codes starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant as defined in the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the wide-character string. If the subject sequence begins with a minus 45836 sign, the value resulting from the conversion is negated. A pointer to the final wide-character string is stored in the object pointed to by endptr, provided that endptr is not a null pointer." To "If the subject sequence has the expected form for a floating-point number, the sequence of wide characters starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant according to the rules of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears in a decimal floating point number, or if a binary exponent part does not appear in a hexadecimal floating point number, an exponent part of the appropriate type with value zero is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the sequence is interpreted as negated. A wide character sequence INF or INFINITY is interpreted as an infinity, if representable in the return type, else like a floating constant that is too large for the range of the return type. A wide character sequence NAN or NAN(n-wchar-sequence opt ) is interpreted as a quiet NaN, if supported in the return type, else like a subject sequence part that does not have the expected form; the meaning of the n-wchar sequences is implementation-dependent. A pointer to the final wide string is stored in the object pointed to by endptr, provided that endptr is not a null pointer. If the subject sequence has the hexadecimal form and FLT_RADIX is a power of 2, the value resulting from the conversion is correctly rounded." _____________________________________________________________________________ objection Enhancement Request Number 656 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 336) [tog-c99-xsh 310] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1509 Line: 45850-45854 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "Upon successful completion, wcstod() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, HUGE_VAL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, 0 shall be returned and errno set to [ERANGE]." To "Upon successful completion, wcstod(), wcstof() and wcstold() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, HUGE_VAL, HUGE_VALF or HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]." _____________________________________________________________________________ objection Enhancement Request Number 657 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 335) [tog-c99-xsh 309] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1509 Line: 45863 Section: wcstod Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "None." To "If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction. If the subject sequence has the decimal form and at most DECIMAL_DIG (defined in ) significant digits, the result should be correctly rounded. If the subject sequence D has the decimal form and more than DECIMAL_DIG significant digits, consider the two bounding, adjacent decimal strings L and U, both having DECIMAL_DIG significant digits, such that the values of L, D, and U satisfy L <= D <= U. The result should be one of the (equal or adjacent) values that would be obtained by correctly rounding L and U according to the current rounding direction, with the extra stipulation that the error with respect to D should have a correct sign for the current rounding direction." _____________________________________________________________________________ objection Enhancement Request Number 658 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 63) [tog-c99-xsh 39] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1509 Line: 45882 Section: wcstoimax Problem: Change required for alignment with C99 (ref C99 section 7.8.2.4). Action: Add the following entry after line 45882: NAME wcstoimax, wcstoumax - convert wide-character string to integer type SYNOPSIS #include #include intmax_t wcstoimax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); uintmax_t wcstoumax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); 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 wcstoimax() and wcstoumax() functions shall be equivalent to the wcstol(), wcstoll(), wcstoul(), and wcstoull() functions except that the initial portion of the wide string shall be converted to intmax_t and uintmax_t representation, respectively. RETURN VALUE The wcstoimax() function shall return the converted value, if any. If no conversion could be performed, zero shall be returned. If the correct value is outside the range of representable values, INTMAX_MAX, INTMAX_MIN,or UINTMAX_MAX shall be returned (according to the return type and sign of the value, if any), and errno is set to [ERANGE]. ERRORS The wcstoimax() and wcstoumax() functions shall fail if: [EINVAL] The value of base is not supported. [ERANGE] The value to be returned is not representable. The wcstoimax() and wcstoumax() functions may fail if: [EINVAL] No conversion could be performed. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO wcstol(), wcstoll(), wcstoul(), wcstoull(), 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 659 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 352) [tog-c99-xsh 326] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1510 Line: 45887 Section: wcstok Problem: Change required for alignment with C99 (ref C99 section 7.24.4.5.7). Action: Change "wchar_t *wcstok(wchar_t * ws1, const wchar_t * ws2, wchar_t **ptr);" To "wchar_t *wcstok(wchar_t * restrict ws1, const wchar_t * restrict ws2, wchar_t ** restrict ptr);" [Ed note: Add to CH The wcstok() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 660 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 337) [tog-c99-xsh 311] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1512 Line: 45938 Section: wcstol Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "long int wcstol(const wchar_t * nptr, wchar_t **endptr, int base);" To "long int wcstol(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); long long int wcstoll( const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base);" [Ed note: Add to CH The wcstol() prototype is updated, and the wcstoll() function added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 661 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 338) [tog-c99-xsh 312] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1512 Line: 45943-45945 Section: wcstol Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "The wcstol( ) function shall convert the initial portion of the wide-character string pointed to by nptr to long int representation. First it decomposes the input wide-character string into three parts:" To "The wcstol() and wcstoll() functions shall convert the initial portion of the wide string pointed to by nptr to long int, long long int, unsigned long int, and unsigned long long int representation, respectively. First, they decompose the input string into three parts: _____________________________________________________________________________ objection Enhancement Request Number 662 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 339) [tog-c99-xsh 313] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1513 Line: 45983 Section: wcstol Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "Because 0, {LONG_MIN}, and {LONG_MAX} are returned on error ..." To "Because 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are returned on error ..." _____________________________________________________________________________ objection Enhancement Request Number 663 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 340) [tog-c99-xsh 314] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1513 Line: 45987 Section: wcstol Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "... wcstol() ..." To "... wcstol() and wcstoll() ..." Same change of lines 45992 and 45995. _____________________________________________________________________________ comment Enhancement Request Number 664 drepper@redhat.com Bug in XSHd3 (rdvk# 20) {ud-27} Thu, 13 Apr 2000 04:02:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: pick up additional entries from XBD 2.1.6.1 (p22-27, l845-1055) _____________________________________________________________________________ Page: 1559-1563 Line: 0 Section: Profiling Problem: The section 4.3.1 Configuration Options misses descriptions for all of the new profiles. The profiles were added to the sysconf() man page but their description is missing. Action: Copy the description from the POSIX standard/draft the profile was taken from. _____________________________________________________________________________ objection Enhancement Request Number 665 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 296) [tog-c99-xsh 270] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1514 Line: 46023 Section: wcstombs Problem: Change required for alignment with C99 (ref C99 section 7.20.8.2). Action: Change "size_t wcstombs(char * s, const wchar_t * pwcs, size_t n);" To "size_t wcstombs(char * restrict s, const wchar_t * restrict pwcs, size_t n);" [Ed note: Add to CH The wcstombs() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 666 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 341) [tog-c99-xsh 315] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1516 Line: 46071 Section: wcstoul Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "long int wcstoul(const wchar_t * nptr, wchar_t **endptr, int base);" To "long int wcstoul(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); long long int wcstoull( const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base);" [Ed note: Add to CH the wcstoul() prototype is updated, and te wcstoull() function added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 667 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 343) [tog-c99-xsh 317] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1517 Line: 46116 Section: wcstoul Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "Because 0 and {ULONG_MAX} are returned on error ..." To "Because 0, {ULONG_MAX} and {ULLONG_MAX} are returned on error ..." _____________________________________________________________________________ objection Enhancement Request Number 668 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 344) [tog-c99-xsh 318] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1517 Line: 46120 Section: wcstoul Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "... wcstoul() ..." To "... wcstoul() and wcstoull() ..." Same change of lines 46125 and 46128. _____________________________________________________________________________ objection Enhancement Request Number 669 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 350) [tog-c99-xsh 324] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1520 Line: 46226 Section: wcsxfrm Problem: Change required for alignment with C99 (ref C99 section 7.24.4.4.4). Action: Change "size_t wcsxfrm(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "size_t wcsxfrm(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" [Ed note: Add to CH The wcsxfrm() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 670 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 354) [tog-c99-xsh 328] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1522 Line: 46295 Section: wctob Problem: Change required for alignment with C99 (ref C99 section 7.24.6.1.2). Action: Change "Otherwise, it shall return the single-byte representation of that character." To "Otherwise, it shall return the single-byte representation of that character as an unsigned char converted to int." _____________________________________________________________________________ objection Enhancement Request Number 671 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 294) [tog-c99-xsh 268] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1523 Line: 46324 Section: wctomb Problem: Change required for alignment with C99 (ref C99 section 7.20.7.2). Action: Change "... If wchar is 0, wctomb( ) is left in the initial shift state." To "... If wchar is 0, a null byte is stored, preceded by any shift sequence needed to restore the initial shift state, and wctomb( ) is left in the initial shift state." _____________________________________________________________________________ objection Enhancement Request Number 672 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 342) [tog-c99-xsh 316] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1516 Line: 56077-46079 Section: wcstoul Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "The wcstoul() function shall convert the initial portion of the wide-character string pointed to by nptr to long int representation. First it decomposes the input wide-character string into three parts:" To "The wcstoul() and wcstoull() functions shall convert the initial portion of the wide string pointed to by nptr to long int, long long int, unsigned long int, and unsigned long long int representation, respectively. First, they decompose the input string into three parts: _____________________________________________________________________________ objection Enhancement Request Number 673 ajosey@rdg.opengroup.org Bug in XSHd3 - c99 (rdvk# 347) [tog-c99-xsh 321] Tue, 18 Apr 2000 21:14:54 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1531 Line: 46558 Section: wmemcpy Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.3). Action: Change "wchar_t *wmemcpy(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wmemcpy(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" [Ed note: Add to CH The wmemcpy() prototype is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 674 donnte@microsoft.com Bug in XSHd3 (rdvk# 613) [DT-XSH-181] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Sorry, but both allowed options are current existing practice. The suggested change would relax current implementation requirements and increase the work portable applications have to do. I have seen scripts where the application really only cared about expanding the first word and only had to check that the first token passed to wordexp() was not '#'; this change would allow implementations to blow up the program in this case. _____________________________________________________________________________ Page: 1534 Line: 46684 Section: wordexp Problem: I (continue) to find it objectionable to offload the inability of vendors to agree on something like this on to the user. In this case, making the behavior undefined is EXACTLY equivalent to saying that the user must deal with comment characters himself, because no matter WHAT the user wants to happen he cannot count upon the interface to portably deliver the behavior he wants. Action: I don't care all that much, but pick one. That way at least the user that wants the same behavior as picked here can count upon always getting it. If picking one is not possible, then at least rephrase this to the implication of the "shall either" is clearer: "The behavior of the wordexp() function when presented with a word beginning with an unquoted comment character (number sign) at the beginning of a token is unspecified. Applications shall ensure that no word begins with a such a character before calling wordexp()." (And in this case, "application shall ensure" is really what's meant... it's a burden on the application, and it's something the application must do.) _____________________________________________________________________________ Objection Enhancement Request Number 675 donnte@microsoft.com Bug in XSHd3 (rdvk# 614) [DT-XSH-182] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Use of terminology is in line with ISO / IEEE guidelines _____________________________________________________________________________ Page: 1535 Line: 46745 Section: wordexp Problem: "can" Action: -> "may". _____________________________________________________________________________ Objection Enhancement Request Number 676 donnte@microsoft.com Bug in XSHd3 (rdvk# 615) [DT-XSH-183] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note to be added to the draft _____________________________________________________________________________ Page: 1540 Line: 46866 Section: write Problem: pwrite() (and pread()) need to be limited to seekable devices or have an explicit statement that the offset argument is ignored. Action: Either. Whichever the original authors intended. _____________________________________________________________________________ Comment Enhancement Request Number 677 donnte@microsoft.com Bug in XSHd3 (rdvk# 616) [DT-XSH-184] Mon, 1 May 2000 11:47:23 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: not possible to drop, they will continue for now as they are, this is decribed in the scope document _____________________________________________________________________________ Page: 1553 Line: 47282 Section: 4 Problem: Does ISO still require this thing (er... section)? If not, I'd suggest dropping it, as it's value is marginal compared to the work to fix it. Action: Drop, if possible.