Document Number: AUSTIN/50 Title: XSHd3 Aardvark Change Request Report Revision Date: 2000-05-24 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 Reject OPEN 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 OPEN 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 OPEN ERN 176 Accept as marked ERN 177 OPEN ERN 178 OPEN 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 OPEN 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 OPEN 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 OPEN 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 OPEN 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 OPEN 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 OPEN 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_____ Duplicate_____ Reject____ OPEN Rationale for rejected or partial changes: NS to submit suitable aardvark _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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_____ Accept as marked below_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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 wishi