Document Number: AUSTIN/62r1 Title: XSHd4 Aardvark Change Request Report Revision Date: 2000-11-23 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XSH Draft 4. Aardvark Summary Table (XSHd4) ______________________ ERN 1 Accept as marked ERN 2 Accept ERN 3 Reject ERN 4 Accept as marked ERN 5 Accept as marked ERN 6 Accept ERN 7 Accept as marked ERN 8 Accept ERN 9 Accept as marked ERN 10 Accept as marked ERN 11 Accept ERN 12 Accept ERN 13 Accept as marked ERN 14 Accept as marked ERN 15 Accept ERN 16 Accept ERN 17 Accept ERN 18 Accept ERN 19 Accept ERN 20 Accept ERN 21 Accept ERN 22 Accept ERN 23 Accept ERN 24 Accept ERN 25 Accept ERN 26 Accept ERN 27 Accept ERN 28 Accept ERN 29 Accept ERN 30 Accept ERN 31 Accept as marked ERN 32 Accept as marked ERN 33 Accept as marked ERN 34 Accept ERN 35 Accept ERN 36 Accept ERN 37 Accept ERN 38 Accept as marked ERN 39 Accept as marked ERN 40 Duplicate of 41 ERN 41 Accept ERN 42 Accept ERN 43 Accept ERN 44 Accept as marked ERN 45 Accept ERN 46 Accept as marked ERN 47 Accept ERN 48 Duplicate of 4 ERN 49 Reject ERN 50 Accept ERN 51 Accept as marked ERN 52 Accept ERN 53 Accept as marked ERN 54 Reject ERN 55 Accept as marked ERN 56 Reject ERN 57 Accept ERN 58 Accept ERN 59 Accept as marked ERN 60 Accept ERN 61 Accept ERN 62 Reject ERN 63 Accept ERN 64 Accept ERN 65 Reject ERN 66 Duplicate of 53 ERN 67 Accept as marked ERN 68 Accept as marked ERN 69 Accept ERN 70 Accept as marked ERN 71 Accept ERN 72 Accept as marked ERN 73 Accept ERN 74 Accept as marked ERN 75 Accept as marked ERN 76 Reject ERN 77 Duplicate of 4 ERN 78 Accept ERN 79 Reject ERN 80 Accept as marked ERN 81 Accept ERN 82 Duplicate of 81 ERN 83 Accept ERN 84 Accept ERN 85 Accept as marked ERN 86 Accept as marked ERN 87 Duplicate of 86 ERN 88 Accept ERN 89 Accept ERN 90 Reject ERN 91 Accept ERN 92 Accept ERN 93 Accept ERN 94 Accept ERN 95 Accept ERN 96 Accept ERN 97 Duplicate of 96 ERN 98 Accept ERN 99 Duplicate of 98 ERN 100 Accept ERN 101 Accept ERN 102 Accept ERN 103 Accept as marked ERN 104 Reject ERN 105 Accept ERN 106 Reject ERN 107 Accept ERN 108 Accept ERN 109 Accept as marked ERN 110 Accept as marked ERN 111 Accept as marked ERN 112 Reject ERN 113 Reject ERN 114 Accept as marked ERN 115 Accept as marked ERN 116 Reject ERN 117 Accept as marked ERN 118 Accept ERN 119 Reject ERN 120 Reject ERN 121 Reject ERN 122 Accept ERN 123 Accept ERN 124 Accept ERN 125 Accept ERN 126 Accept ERN 127 Duplicate of 126 ERN 128 Reject ERN 129 Reject ERN 130 Accept ERN 131 Accept ERN 132 Reject ERN 133 Reject ERN 134 Reject ERN 135 Accept ERN 136 Accept ERN 137 Accept ERN 138 Accept ERN 139 Accept ERN 140 Accept ERN 141 Accept ERN 142 Accept as marked ERN 143 Duplicate of 142 ERN 144 Accept ERN 145 Accept ERN 146 Accept ERN 147 Accept as marked ERN 148 Accept ERN 149 Accept ERN 150 Accept ERN 151 Accept ERN 152 Accept ERN 153 Accept as marked ERN 154 Accept ERN 155 Accept ERN 156 Accept as marked ERN 157 Accept ERN 158 Accept ERN 159 Accept as marked ERN 160 Reject ERN 161 Accept ERN 162 Accept as marked ERN 163 Reject ERN 164 Reject ERN 165 Accept as marked ERN 166 Accept ERN 167 Accept ERN 168 Accept ERN 169 Accept ERN 170 Accept as marked ERN 171 Accept ERN 172 Accept ERN 173 Reject ERN 174 Accept ERN 175 Accept ERN 176 Accept ERN 177 Accept ERN 178 Reject ERN 179 Accept ERN 180 Accept ERN 181 Accept as marked ERN 182 Accept ERN 183 Accept ERN 184 Accept as marked ERN 185 Accept as marked ERN 186 Accept ERN 187 Accept ERN 188 Accept ERN 189 Accept ERN 190 Accept ERN 191 Accept as marked ERN 192 Reject ERN 193 Accept ERN 194 Reject ERN 195 Accept ERN 196 Accept as marked ERN 197 Accept ERN 198 Accept ERN 199 Reject ERN 200 Accept ERN 201 Duplicate of 200 ERN 202 Accept as marked ERN 203 Accept as marked ERN 204 Accept as marked ERN 205 Accept ERN 206 Accept as marked ERN 207 Accept ERN 208 Accept as marked ERN 209 Accept ERN 210 Accept as marked ERN 211 Accept as marked ERN 212 Reject ERN 213 Reject ERN 214 Accept ERN 215 Accept as marked ERN 216 Accept ERN 217 Accept as marked ERN 218 Accept ERN 219 Accept as marked ERN 220 Duplicate of 219 ERN 221 Duplicate of 219 ERN 222 Accept ERN 223 Accept as marked ERN 224 Accept ERN 225 Accept ERN 226 Accept ERN 227 Duplicate of 229 ERN 228 Accept as marked ERN 229 Accept ERN 230 Accept ERN 231 Accept ERN 232 Accept as marked ERN 233 Reject ERN 234 Accept ERN 235 Reject ERN 236 Duplicate of 237 ERN 237 Accept as marked ERN 238 Accept ERN 239 Accept as marked ERN 240 Accept ERN 241 Accept ERN 242 Accept ERN 243 Accept ERN 244 Accept ERN 245 Reject ERN 246 Accept ERN 247 Reject ERN 248 Accept as marked ERN 249 Accept as marked ERN 250 Reject ERN 251 Accept ERN 252 Accept ERN 253 Accept ERN 254 Accept as marked ERN 255 Accept ERN 256 Duplicate of 257 ERN 257 Accept ERN 258 Reject ERN 259 Duplicate of 210 ERN 260 Accept ERN 261 Accept ERN 262 Accept ERN 263 Accept ERN 264 Accept ERN 265 Accept ERN 266 Accept ERN 267 Accept ERN 268 Reject ERN 269 Accept ERN 270 Accept ERN 271 Accept ERN 272 Duplicate of 273 ERN 273 Accept ERN 274 Reject ERN 275 Accept ERN 276 Accept as marked ERN 277 Accept ERN 278 Reject ERN 279 Accept ERN 280 Accept as marked ERN 281 Accept ERN 282 Accept ERN 283 Accept ERN 284 Accept as marked ERN 285 Accept ERN 286 Accept ERN 287 Accept ERN 288 Accept as marked ERN 289 Accept ERN 290 Accept as marked ERN 291 Accept ERN 292 Accept ERN 293 Accept ERN 294 Accept ERN 295 Accept ERN 296 Reject ERN 297 Accept as marked ERN 298 Accept ERN 299 Accept as marked ERN 300 Accept ERN 301 Accept as marked ERN 302 Accept as marked ERN 303 Reject ERN 304 Accept ERN 305 Accept ERN 306 Accept ERN 307 Accept ERN 308 Accept ERN 309 Accept ERN 310 Accept as marked ERN 311 Accept as marked ERN 312 Accept as marked ERN 313 Reject ERN 314 Accept as marked ERN 315 Accept ERN 316 Accept ERN 317 Reject ERN 318 Reject ERN 319 Reject ERN 320 Accept ERN 321 Accept as marked ERN 322 Reject ERN 323 Reject ERN 324 Accept as marked ERN 325 Accept as marked ERN 326 Accept ERN 327 Reject ERN 328 Accept ERN 329 Accept ERN 330 Accept ERN 331 Accept as marked ERN 332 Accept ERN 333 Accept ERN 334 Accept ERN 335 Accept ERN 336 Accept ERN 337 Accept as marked ERN 338 Accept ERN 339 Accept ERN 340 Accept ERN 341 Accept ERN 342 Accept ERN 343 Accept as marked ERN 344 Accept as marked ERN 345 Accept as marked ERN 346 Accept as marked ERN 347 Accept ERN 348 Reject ERN 349 Accept as marked ERN 350 Accept ERN 351 Accept ERN 352 Accept ERN 353 Accept ERN 354 Accept as marked ERN 355 Accept as marked ERN 356 Accept ERN 357 Accept as marked ERN 358 Duplicate of 357 ERN 359 Accept ERN 360 Accept as marked ERN 361 Accept as marked ERN 362 OPEN ERN 363 OPEN ERN 364 Accept ERN 365 Duplicate of 364 ERN 366 Accept ERN 367 Accept as marked ERN 368 Accept ERN 369 Accept ERN 370 Accept ERN 371 Accept ERN 372 Accept ERN 373 Accept ERN 374 Accept as marked ERN 375 Reject ERN 376 Accept as marked ERN 377 Accept as marked ERN 378 Accept ERN 379 Accept ERN 380 Accept ERN 381 Reject ERN 382 Accept ERN 383 Accept ERN 384 Accept as marked ERN 385 Accept ERN 386 Reject ERN 387 Accept as marked ERN 388 Accept ERN 389 Accept ERN 390 Accept ERN 391 Accept ERN 392 Accept ERN 393 Accept ERN 394 Accept 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 ERN 405 Accept ERN 406 Accept ERN 407 Accept as marked ERN 408 Accept ERN 409 Duplicate of 327 _____________________________________________________________________________ editorial Enhancement Request Number 1 Jon.Hitchcock@uniplex.co.uk Bug in XSHd4 Change history (rdvk# 311) {jjh12} Mon, 25 Sep 2000 20:06:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 0 Line: 0 Section: Change Problem: Line 7155 (closedir) says "the inclusion of is no longer required". This is not true because it was already optional in Issues 4 and 5. The line is unnecessary because lines 7158-7160 explain that although the header was required by previous POSIX specifications the requirement has been removed, and the removal of the OH-shaded line from the synopsis is consequence of that change. Action: Remove line 7155, and also remove similiar lines from the change history of all functions which have an explanation similiar to lines 7158-7160. [Ed recommendation: Accept as marked. The following is notes to the editor to resolve this correctly. Where this standard string (Stdtext/0f) is followed by standard string sequence ./Stdtext/2a, then we need to replace ./Stdtext/0f with a new string "In the SYNOPSIS, the optional include of the header is removed" Do this for closedir, creat, fcntl, fstat, getegid, geteuid, getgid, getgrgid, getgrnam, getgroups,getpgrp, getpid,getppid, getpwnam, getpwuid,getuid,kill,lseek,mkdir, mkfifo,opendir,open, regcomp,rewinddir,setgid,setpgid,setsid,setuid,stat,tcgetpgrp, umask,utime,wait] _____________________________________________________________________________ Editorial Enhancement Request Number 2 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 343) [DWC-816] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: (set errno to 0, call function, check errno) Several function descriptions in this document contain two paragraphs at the end of the DESCRIPTION section saying something like: The xxx() function shall not change the setting of errno if successful. Because 0 is returned on error and is also a valid return on success, an application wishing to check for error situations should set errno to 0, then call xxx(), then check errno. This is good advice, but these lines are an extension to C99 and are not marked CX. Furthermore, the suggestion to set errno to zero, call the function, and then check errno applies to all functions described on these pages, not just the first function in the synopsis section. The changes suggested below will make these pages match the markings currently on the strcoll() page (P1924, L43757-43759) and a few other pages. Action: Shade P1957, L44871-44873 using the CX margin code. Change "0, then call strtod()," on P1957, L48873 to "0; then call strtod(), strtof(), or strtold();" on P1957, L48873 Shade P1965, L45133-45136 using the CX margin code. Change "0, then call strtol()," on P1965, L45136 to "0, then call strtol() or strtoll(),". Shade P1968, L45231-45234 using the CX margin code. Change "0, then call strtoul()," on P1968, L45233-45234 to "0, then call strtoul() or strtoull(),". Shade P2128, L50068-50070 using the CX margin code. Change "0, then call wcstod()," on P2128, L50070 to "0; then call wcstod(), wcstof(), or wcstold();". Shade P2134, L50269-50272 using the CX margin code. Change "0, then call wcstol()," on P2134, L50272 to "0, then call wcstol() or wcstoll(),". Shade P2139, L50406 using the CX margin code. Change "0, then call wcstoul()," on P2139, L50409 to "0, then call wcstoul() or wcstoull(),". Shade P2143, L50532-50533 using the CX margin code. [Ed recommendation: NONE I was tempted to accept, but thought I should note that this was APP USAGE in Issue 4 V2 and earlier and could be a candidate to go back to APP USAGE] ------------------------------------------------------------------------------ _______________________________________________________________________________ objection Enhancement Request Number 3 roysterc@ncr.disa.mil Bug in XSHd4 entire Document (rdvk# 371) {App usage section(s)/entire document} Wed, 27 Sep 2000 03:26:09 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See the Ed recommendation _______________________________________________________________________________ Page: 0 Line: 0 Section: entire Problem: Need to identify all of the different types of Feature Groups b4 approving this draft. Action: In the Front section of the document. List all the types of feature groups with their meanings. Also, list if a particular API/function is part of an existing profile like 1003.13:1998 etc. The application usage section should indicate if a function/API is listed in 1003.13:1998. If an API is not noted, this would be helpful to the implementor/user of the spec. [Ed recommendation: Reject If we make this change we'd need to update this standard each time a new profile is written. Also see response to XBDd4 ERN 2] _____________________________________________________________________________ Objection Enhancement Request Number 4 donnte@microsoft.com Bug in XSHd4 Functions (rdvk# 407) [DST-178] Thu, 28 Sep 2000 09:14:32 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: just ualarm and usleep marked as OB. in their SYNOPSIS lines Add to change history These functions are marked obsolescent _____________________________________________________________________________ Page: all Line: all Section: all Problem: In addition to the specific items listed above, apply whatever notation we use for "do not use for new applications" to the following interfaces (there may be some repitition): _longjmp creat lockf (or fcntl locking) shm* sem* msg* putenv rand (yes, it's required by C, but that doesn't mean we can't flag it; we just can't delete it.) toascii (misleading name/function easily implemented inline) ualarm ulimit usleep Action: Mark "do not use", whatever that is. Upon agreement in principle, I'll look up all the relevant page numbers. _____________________________________________________________________________ Objection Enhancement Request Number 5 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 231) [DST-96] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add With each function or header from the C standard, a statement to the effect that "any conflict is unintentional" is included. That is intended to refer to a direct conflict. This standard acts in part as a profile of the C standard, and it may choose to further constrain behaviors allowed to vary by the C standard. Such limitations are not considered conflicts. _____________________________________________________________________________ Page: 502 Line: 294 Section: 1.6 Problem: There are various interpretations of the word "conflict", as used in the introduction to each function derived from the C standard. In particular, a pedantic reading could be that "if the C standard says it's implementation defined, that's a conflict, and I can do what I want, rather than what POSIX wants." Action: Add (here): With each function from the C standard, a statement to the effect that "any conflict is unintentional" is included. That is intended to refer to a direct conflict. This standard acts in part as a profile of the C standard, and it may choose to further constrain behaviors allowed to vary by the C standard. Such limitations are not considered conflicts, and implementations and applications conforming to this standard are expected to conform to any profiling of the C standard as well. _____________________________________________________________________________ editorial Enhancement Request Number 6 prindle@voicenet.com Bug in XSHd4 (rdvk# 36) [prindle.xsh-1] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 505 Line: 456 Section: 1.9.3 Problem: The option "Threads Priority Inheritance" should be "Thread Priority Inheritance". Action: Make it so [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 7 prindle@voicenet.com Bug in XSHd4 (rdvk# 37) [prindle.xsh-2] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 506 Line: 480 Section: 1.9.3 Problem: I don't understand the alphabetization in this section. It seems neither by code or by option name. By option name seems most appropriate, but this list is neither. Action: Make this list alphabetical by option name. [Ed recommendation: Accept as marked. There are three codes out of order (tef,trl,tri), the order is alphabetical by code ] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 8 prindle@voicenet.com Bug in XSHd4 (rdvk# 38) [prindle.xsh-3] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 509 Line: 579-581 Section: 1.10 Problem: This wording assumes error values are only returned in errno. Some functions return the error values directly in the return code. Action: Change to: This section gives the symbolic names of the error values returned by a function or stored into a variable accessed through the symbol errno if an error occurs. "No errors are defined" means that error values returned by a function or stored into a variable accessed through the sumbol errno, if any, depend on the implementation. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 9 prindle@voicenet.com Bug in XSHd4 (rdvk# 39) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 511 Line: 618 Section: 2.1 [prindle.xsh-4] Problem: This section (beginning on this line) is the first use of the undefined term "library function". I believe this was intended to mean any function defined by this standard, or by an implementor as an extension to this standard. I do not believe it applies to functions in general, such as those supplied in a third-party library, or those that are part of an application. Likewise for the (rare) occurrences outside this section. Action: Define the term "library function" (in XBD) as: Any C-Language function defined in this standard or defined by an implementation as an extension to this standard. [Ed recommendation: Accept as marked: Change "library function" to "function" on page 511 lines 618, 622,625,630 page 595 line 3705 XCUd4 page 2428 line 8279 XCUd4 page 2431 line 8385] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 10 prindle@voicenet.com Bug in XSHd4 (rdvk# 40) [prindle.xsh-5] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 513 Line: 678-679 Section: 2.2.1.2 Problem: There is no symbol _POSIX_SOURCE defined by this standard. Action: Remove all references to _POSIX_SOURCE from these lines. [Ed recommendation: Accept as marked. Delete "either _POSIX_SOURCE or" on line 678 Delete "_POSIX_SOURCE is defined, or" on line 679 ] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 11 prindle@voicenet.com Bug in XSHd4 (rdvk# 41) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 517-520 Line: 833-947 Section: 2.2.2 [prindle.xsh-6] Problem: Formatting problem. Change bars lie on top of text, extra change bars all over the place. Action: Make it right. [Ed recommendation: Accept, this will not appear as is in the final draft - this is also covered in the reviewers note as a known problem] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 12 adjg@eng.sun.com Bug in XSHd4 (rdvk# 148) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 520 Line: 939-40 Section: compilation Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), getipnodebyname(). _____________________________________________________________________________ comment Enhancement Request Number 13 prindle@voicenet.com Bug in XSHd4 (rdvk# 42) [prindle.xsh-7] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 520 Line: 948-949 Section: 2.2.2 Problem: This paragraph overrides all of the prior tables except for the unnumbered table on page 517-518, and then only the reserved for future use functions. Action: Remove all the enumerated function tables except for one which lists only the ISO C functions reserved for future use and not defined in this standard. They are unnecessary since they are covered implicitly by lines 948-949. [Ed recommendation: Accept as marked, delete lines 905-947] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 14 prindle@voicenet.com Bug in XSHd4 (rdvk# 43) [prindle.xsh-8] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add description of size_t to regex.h in XBD (is declared as described in ). _____________________________________________________________________________ Page: 520 Line: 955-957 Section: 2.2.2 Problem: I do not believe this paragraph is true unless XSI extensions are enabled (i.e. an optional header such as in XSI is a required header in POSIX, and may define types required by the subsequent header). Action: Shade this paragraph and mark with margin code XSI. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 15 prindle@voicenet.com Bug in XSHd4 (rdvk# 44) [prindle.xsh-9] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 521 Line: 967-969 Section: 2.3 Problem: The ISO C 99 standards says: "It is unspecified whether errno is a macro or an identifier declared with external linkage." To require it to be a macro is an extension to ISO C, and one which is not at all desirable: Requiring that errno BE a macro is problematical. It should not be required to be a macro (it need not be in single-threaded applications), but should be allowed to be a macro. A common example of application failure due to macro-ization of errno is the simple C++ construct ::errno, which is a valid reference to the modifyable lvalue errno in global scope (i.e. the value we are talking about here), but is a syntax error if errno is a macro that expands to a dereferenced function call. Implementations I have seen overcome this by making errno a macro only if the application explicitly specifies a requirement for reentrant errno. Implementations should also be free to implement errno as a per-thread object in other ways, e.g. in a uni-processor maintaining its per-thread value on each context switch. Note that this standard says of errno that it is reserved for use as an identifier with external linkage. That would normally not prohibit applications from using errno in other contexts such as a member of a struct/class. But when errno is a macro, such usages are usually rendered to syntax errors. Another good reason to allow the user to switch off macro errno when it isn't needed. Action: For consistency with the errno page (which is correct), change the last sentence to: The symbol errno, defined by including the header, expands to a modifyable lvalue of type int. It is unspecified whether errno is a macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name errno, the behavior is undefined. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 16 prindle@voicenet.com (rdvk# 383) [prindle.xsh-167] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept (also l 8146 p249 if XBD) _____________________________________________________________________________ Page: 526 Line: 1226 Section: 2.3 Problem: There are two quite different definitions of this error given on the same line. I believe (given that the strerror() of EPROTOTYPE is "Protocol wrong type for socket" in several implementations) the first if incorrect, and the second is correct. To me, "Socket type not supported" means not supported at all, i.e. by the implementation. Action: Change this line to: Protocol wrong type for socket. The socket type is not supported by the protocol. Fix comment on corresponding line in in XBD to include the first part of this def. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 17 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 357) {aj.tog.26sep.8} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 528 Line: 1275 Section: 2.4.1 Problem: wording - shallification Action: Change "a determination is made" to "a determination shall be made" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 18 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 358) {aj.tog.26sep.9} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 528 Line: 1277 Section: 2.4.1 Problem: wording - shallification Action: Change "are generated" to "shall be generated" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 19 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 359) {aj.tog.26sep.10} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 528 Line: 1279 Section: 2.4.1 Problem: wording - shallification Action: Change "are generated" to "shall be generated" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 20 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 360) {aj.tog.26sep.11} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 529 Line: 1328 Section: 2.4.2 Problem: wording - shallification Action: Change "is defined" to "shall be defined" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 21 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 361) {aj.tog.26sep.12} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 529 Line: 1354 Section: 2.4.2 Problem: wording - shallification Action: Change "is defined" to "shall be defined" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 22 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 362) {aj.tog.26sep.13} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 530 Line: 1359 Section: 2.4.2 Problem: wording - shallification Action: Change "is used" to "shall be used" The same on line 1360 [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 23 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 363) {aj.tog.26sep.14} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 530 Line: 1369 Section: 2.4.2 Problem: wording - shallification Action: Change "have no effect" to "shall have no effect" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 24 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 364) {aj.tog.26sep.15} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 530 Line: 1375 Section: 2.4.2 Problem: wording - shallification Action: Change "signal remains pending. Otherwise, the pending indication is reset" to "signal shall remain pending. Otherwise, the pending indication shall be reset" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 25 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 365) {aj.tog.26sep.16} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 530 Line: 1393 Section: 2.4.2 Problem: wording - shallification Action: Change "are to terminate" to "shall be to terminate" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 26 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 366) {aj.tog.26sep.17} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 532 Line: 1450 Section: 2.4.3 Problem: wording - shallification Action: Change "contains the signal number" to "shall contain the signal number" On the same line change "This is the same" to "This shall be the same" On line 1451 change "contains a code" to "shall contain a code" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 27 prindle@voicenet.com Bug in XSHd4 (rdvk# 45) [prindle.xsh-10] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 532 Line: 1451 Section: 2.4.3 Problem: Shading is discontinuous on this line. The Note to Reviewers below also applies to this line. Action: Entire line should be shaded. Make it so and fix shading referred to by Note to Reviewers also. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 28 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 367) {aj.tog.26sep.18} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 532 Line: 1471 Section: 2.4.3 Problem: wording - shallification Action: Change "si_value contains" to "si_value shall contain [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 29 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 368) {aj.tog.26sep.19} Tue, 26 Sep 2000 16:55:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 532 Line: 1484 Section: 2.4.3 Problem: wording - shallification Action: Change "that are either reentrant or not interruptable by signals and are async-signal safe" to "that shall be either reentrant or non-interruptable by signals and shall be async-signal safe" [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 30 prindle@voicenet.com Bug in XSHd4 (rdvk# 47) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 533 Line: 1513-1515 Section: 2.4.3 [prindle.xsh-12] Problem: The functions sigpause() and sigset(), named here as Realtime functions, are not. They are XSI functions. Action: List these two functions under the heading "XSI functions". [Ed recommendation: Accept as marked, merge all of the functions into a single table, the utility of the split out tables is minimal] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 31 prindle@voicenet.com Bug in XSHd4 (rdvk# 48) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI 2000-10-35, this has the words _____________________________________________________________________________ Page: 534 Line: 1535-1538 Section: 2.4.4 [prindle.xsh-13] Problem: I agree with that a discrepancy exists and hope that it is resolved in favor of the former sentence, and not the latter. Action: Finalize the interp only if it recommends adding "with the single exception noted on line 1521 above" or something to that effect, to make the latter sentence consistent with the former. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 32 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 243) [DST-159] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Insert the following text on line 1714, after "...protocol modules." "STREAMS modules are unspecified objects. Access to STREAMS modules is provided by interfaces in this standard. Creation of STREAMS modules is outside the scope of this standard.". Insert new paragraph and continue text at end of 1714 "A STREAM..." _____________________________________________________________________________ Page: 539 Line: 1713 Section: 2.6 Problem: I think I see the problem I'm having with streams: the I/O interfaces are defined, but nowhere does it say what they are or how they are created. That appears to be intentional, based on a clause buried in the middle of line 1717. But that's overly subtle. Action: Add before 1713: STREAMS modules are unspecified objects created by the implementation, to which access is provided by the interfaces in this standard. Creation of STREAMS modules is outside the scope of this standard. If that statement isn't true, then there need to be additions to the standard to make it clear how streams are created and installed. _____________________________________________________________________________ Objection Enhancement Request Number 33 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 244) [DST-160] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Insert after the end of the sentence on 1878: Since there is no way for a strictly conforming application to determine if this relaxation applies, all strictly conforming applications which rely on ordering of output shall be written in such a way hat will operate correctly if the relaxation applies. _____________________________________________________________________________ Page: 544 Line: 1877 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: Truth in advertising requires us to say (insert after end of sentence on 1878): Since there is no way for a strictly conforming application to determine if this relaxation applies, all strictly conforming applications which rely on ordering of output must be written in such a way that it will operate correctly if the relaxation applies. (A conforming application's owner may use the conformance document to determine whether it will run correctly or not.) _____________________________________________________________________________ Comment Enhancement Request Number 34 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 331) [DWC-804] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 546 Line: 2000-2001 Section: 2.8.4 Problem: (process scheduling) The second sentence in this paragraph can be misread to mean that a runnable thread with priority x can be on a thread list for priority y. Action: Change: Any runnable thread may be on any thread list. to: Any runnable thread may be on any thread list for that thread's priority. ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 35 ajosey@opengroup.org Bug in XSHd4 2.8.4 (rdvk# 35) {tog.aug31.1} Thu, 31 Aug 2000 09:24:50 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 550 Line: 2144 Section: 2.8.4 Problem: wording change caused loss of strict conformance requirement for applications. Action: change "portable applications" -> "strictly conforming applications" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 36 ajosey@opengroup.org Bug in XSHd4 SCHED_OTHER (rdvk# 187) {tog.sep21.1} Thu, 21 Sep 2000 14:31:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 550 Line: 2144 Section: SCHED_OTHER Problem: This reads better to me if the "in a portable manner" is moved up in the sentence. Action: Change "This policy is defined to allow conforming applications to be able to indicate that they no longer need a realtime scheduling policy in a portable manner". to "This policy is defined to allow conforming applications to be able to indicate in a portable manner that they no longer need a realtime scheduling policy". [Ed recommendation:Accept] _____________________________________________________________________________ editorial Enhancement Request Number 37 prindle@voicenet.com Bug in XSHd4 (rdvk# 49) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 551 Line: 2191,2199 Section: 2.8.5 [prindle.xsh-14] Problem: Margin codes MON do not align with shading. Action: Align them. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 38 prindle@voicenet.com Bug in XSHd4 (rdvk# 183) [prindle.xsh-95] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 553 Line: 2240-2247 Section: 2.9.1 Problem: The functions getdate() and localeconv() is not listed in this table. Action: Add getdate() and localeconv() to the upper table, alphabetically merged in the right place. [Ed recommendation: Accept as marked. localeconv() should be added to the upper table. The getdate() function is an XSI function and is already listed in the lower table] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 39 al.simons@compaq.com Bug in XSHd4 (rdvk# 93) [Simons-Compaq-3] Tue, 05 Sep 2000 15:55:16 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 553 Line: 2251 Section: 2.9.1 Problem: getenv() is incorrectly listed in the XSI table. It is a base function. Action: Remove getenv() from the XSI table. [Ed recommendation: Accepted as marked, note the page number was corrected to 553] _____________________________________________________________________________ objection Enhancement Request Number 40 prindle@voicenet.com Bug in XSHd4 (rdvk# 182) [prindle.xsh-94] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_41 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 553 Line: 2252 Section: 2.9.1 Problem: NOTE: THIS IS A CORRECTION TO [prindle.xsh-72] WHICH LISTED THE INCORRECT PAGE NUMBER!!! The function strerror() is listed in the wrong table. It is not XSI. In fact it is from ISO C. Action: Move strerror() from the shaded table to the non-shaded table above. [Ed recommendation: DUP of xsh-72: the page number was corrected] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 41 prindle@voicenet.com Bug in XSHd4 (rdvk# 135) [prindle.xsh-72] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 553 Line: 2252 Section: 2.9.1 Problem: The function strerror() is listed in the wrong table. It is not XSI. In fact it is from ISO C. Action: Move strerror() from the shaded table to the non-shaded table above. [Ed recommendation: ACCEPT : Take the change a noted above, but note that the shading does not denote whether its an XSI function, but whether the function is thread-safe. In XSH5 there appeared to be some doubt as to whether POSIX.1-1996 required it (no reentrant version was provided), and the shading was put in place to make the requirement clear for XSI systems. Given the changes in the draft and Interp 1003.1c#39, the change should be made] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 42 David.Butenhof@compaq.com Bug in XSHd4 2.9.1 (rdvk# 94) {drb.xshd4.001} Mon, 11 Sep 2000 14:28:17 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 553 Line: 2259 Section: 2.9.1 Problem: Though somewhat corrected over the text in draft 3, the draft 4 version still claims that "The read() function need not be thread-safe..." As discussed previously, (and as draft 4 notes in the paragraph that follows, starting with line 2261 on the same page), the read() function must be thread-safe. The read() function is actually allowed only to violate one commonly inferred side-effect of "thread-safety" (for certain devices) by breaking the requested operation into several atomic (and individually thread-safe) blocks. Action: Remove the paragraph at line 2259, "The read() function need not be thread-safe... when reading from a pipe, FIFO, socket, or terminal device." This statement is incorrect, as all read() operations must be thread-safe. The following Note is correct and sufficient. While thread-safe, some operations on the noted device types may result in a finite sequence of individually atomic (thread-safe) operations. The operations are always "thread-safe", but the lack of overall atomicity may result in application-visible complications for which the code may need to compensate. _____________________________________________________________________________ comment Enhancement Request Number 43 prindle@voicenet.com Bug in XSHd4 (rdvk# 50) [prindle.xsh-15] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 555 Line: 2302 Section: 2.9.4 Problem: This entire section is dependent on the Thread Execution Scheduling option TPS. Action: Add after this line: The functionality described in this section is dependent on support of the Thread Execution Scheduling option (and the rest of this section is not further shaded for this option). Shade and mark with margin code TPS. Delete lines 2304-2305, which are now redundant. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 44 prindle@voicenet.com Bug in XSHd4 (rdvk# 169) Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the paragraph at p560 l 2494: Whenever a thread has cancelability enabled and a cancellation request has been made with that thread as the target, and the thread then calls any function that is a cancellation point (such as pthread_testcancel(), or read()), the cancellation request shall be acted upon before the function returns. If a thread has cancelability enabled and a cancellation request is made with the thread as a target while the thread is suspended at a cancellation point, the thread shall be awakened and the cancellation request shall be acted upon. However, if the thread is suspended at a cancellation point and the event for which it is waiting occurs before the cancellation request is acted upon, it is unspecified whether the cancellation request is acted upon or whether the cancellation request remains pending and the thread resumes normal execution. _____________________________________________________________________________ Page: 560 Line: 2496-2498 Section: 2.9.5.2 [prindle.xsh-81] Problem: The wording of the sentence is too vague. It was meant to convey that it is a requirement that cancelation be acted upon if all three of these conditions become true in any order (this confirmed by Dave Butenhof), but is not strong enough to do that. The intention is to require that a thread with cancelability enabled and suspended at a cancelation point shall be canceled if a pthread_cancel() is subsequently done on that thread while it is still suspended. Readers are having difficulty reading that requirement into this statement as it stands. I have submitted a PASC interpretation request to formally bring this clarification within the scope of the 1003.1 revision PAR. Action: Add to the end of the sentence, before the period: "regardless of the order in which these three conditions become true" ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 45 prindle@voicenet.com Bug in XSHd4 (rdvk# 51) Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 560 Line: 2528 Section: 2.9.6 [prindle.xsh-16] Problem: The hyphenated phrase "read-only" does not work well as a verb. In fact, I'm not convinced it's even legal English. Action: Change "read-only" on this line to "read" (i.e. the passive verb, pronounced red). [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 46 gwinn@res.ray.com Bug in XSHd4 2.10.6 (rdvk# 370) {JMG-5} Wed, 27 Sep 2000 00:08:39 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: New text is being added to include the Raw Sockets option as per XBD ERN 52. _____________________________________________________________________________ Page: 563 Line: 2587-2591 Section: 2.10.6 Problem: The raw sockets option is ommitted. Action: See JMG-3 concerning _POSIX_RAW_SOCKETS. _____________________________________________________________________________ Objection Enhancement Request Number 47 adjg@eng.sun.com Bug in XSHd4 (rdvk# 149) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 571 Line: 2940 Section: sockets Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Change getipnodebyname() to getaddrinfo(). _____________________________________________________________________________ Comment Enhancement Request Number 48 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 228) [DST-93] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_4 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 588 Line: 3547 Section: _longjmp Problem: Can we do that now (or mark obsolescent). I strongly believe we need an explicit marking, not a comment, on interfaces that we believe new programs should not be using. Action: Mark obsolescent. (Or...) _____________________________________________________________________________ Objection Enhancement Request Number 49 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 229) [DST-94] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Reject - these interfaces have been internationalized for 10-12 years, and do not need to revert at this point. _____________________________________________________________________________ Page: 591 Line: 3570 Section: _tolower Problem: Historically, the macros _toupper and _tolower have explicitly NOT honored the locale (that is, they were a simple mask operation that worked on ASCII only). Action: Choose 1: Revert the description to the historical implementation. Or Expliclity acknowledge the change in semantics (in Revision History, probably). (To be honest, I don't remember when I first saw these; it may be as far back as System III, but historicaly they were not internationalized when I first saw them, and that seemed intentional.) [Ed recommendation: NONE I'm favoring a reject here, since these functions have been internationalized since at least XPG3] _____________________________________________________________________________ objection Enhancement Request Number 50 prindle@voicenet.com Bug in XSHd4 (rdvk# 52) [prindle.xsh-17] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: CX shading to the end of the para _____________________________________________________________________________ Page: 595 Line: 3695-3696 Section: abort() Problem: The last sentence of this paragraph is not shown as a C extension. But I cannot find this requirement anywhere in the C99 standard, and furthermore, C99 does not speak to blocking a signal, only ignoring. Action: Shade the last sentence and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 51 prindle@voicenet.com Bug in XSHd4 (rdvk# 53) [prindle.xsh-18] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 595 Line: 3704-3707 Section: abort() Problem: This app-usage is a bunch of doubletalk. It says nothing comprehensible, conflicts with normative text (i.e. regarding overriding ignoring), and references a discussion of SIGABRT that is non-existent. Action: Take it out (or reconstruct what was originally intended to be here). [Ed recommendation: Accept as marked, delete line 3305- "If SIGABRT is neither caught nor ignored, then the actions associated with SIGABRT defined in Section 2.4.1 (on page 528) will be taken." Change "library functions" to "functions" on line 3305] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 52 ajosey@opengroup.org Bug in XSHd4 (rdvk# 90) {tog.sep4.1} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 603 Line: 3955 Section: acos Problem: on line 3955 change "andis" to "and is" Action: as per problem statement [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 53 prindle@voicenet.com Bug in XSHd4 (rdvk# 54) [prindle.xsh-19] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being handled by the revision to the error handling being applied globally to all the maths functions. _____________________________________________________________________________ Page: 605 Line: 3994 Section: acosh() Problem: These are c99 functions, and as such need to have the standard disclaimer added. Also, it does not appear that c99 requires these functions to return NaN, so references to NaN returns need to be shaded. Action: Add after this line: 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. Shade and margin code CX references to returning NaN on error. (Follow acos() as a guideline) ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 54 ajosey@opengroup.org Bug in XSHd4 (rdvk# 88) {tog.sep4.3} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: OBE by 53 _____________________________________________________________________________ Page: 605 Line: 4005 Section: acosh Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions . Action: XSI shade line 4005-4006 and 4015 _____________________________________________________________________________ comment Enhancement Request Number 55 bmark@us.ibm.com Bug in XSHd4 aio_fsync (rdvk# 369) {(msb.ibm.1)} Tue, 26 Sep 2000 23:10:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: An interpretation has been submitted PASC 1003.1 #118 Add a reviewers note referencing the interpretation and the problem statement. _____________________________________________________________________________ Page: 610 Line: 4143 Section: aio_fsync Problem: This text has caused some confusion among implementors, to whit: The description of the aiocbp struct describes its use in multiple functions, but then says that all elements but aio_sigevent are ignored. Obviously the context should be "when used in aio_fsync()", right? Action: Start the sentence at line 4151 with "When used in aio_fsync()," . _____________________________________________________________________________ objection Enhancement Request Number 56 prindle@voicenet.com Bug in XSHd4 (rdvk# 55) [prindle.xsh-20] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 621 Line: 4468 Section: alarm() Problem: C99 clearly prefers "unsigned int" over the anachronistic synonym "unsigned". The 1996 standard uses "unsigned int". There is no reason to change it. Action: Change all occurrences of "unsigned" (the type) on this page to "unsigned int". [Ed recommendation: reject, this was a consequence of accepting D3 rdvk XBDd3 ERN1 ] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 57 prindle@voicenet.com Bug in XSHd4 (rdvk# 56) [prindle.xsh-21] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 621 Line: 4477 Section: alarm() Problem: This is an XSI extension. Action: Shade and mark XSI. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 58 prindle@voicenet.com Bug in XSHd4 (rdvk# 57) [prindle.xsh-22] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 623 Line: 4576 Section: asctime() Problem: The wording in the 1996 standard was correct according to your definition of "shall" on page 497, line 204, WRT applications. The current phrase "contains" is non-normative. Action: Replace "which contains at least 26 bytes" by "which shall contain at least 26 bytes". [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 59 prindle@voicenet.com Bug in XSHd4 (rdvk# 67) [prindle.xsh-32] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 635 Line: 4835 Section: atexit() Problem: The text that is shaded and marked CX on this page does not appear to be an extension to ISO C. However, the exact ISO C semantics are not exactly what is shown here. The exact ISO C semantics are correctly quoted in exit(), and should be used here too. Action: Remove shading, and replace "in the reverse order of their registration" with: "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". [Ed recommendation: Accept as marked, make the change above, also add to the CH: The description is updated for alignment with ISO/IEC 9899:1999.] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 60 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 230) [DST-95] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 647 Line: 5195 Section: bsd_signal Problem: Mark obsolescent (or whatever). Action: Do it. [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 61 prindle@voicenet.com (rdvk# 196) [prindle.xsh-104] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 647 Line: 5515 Section: calloc() Problem: See also page 1247 line 24259 section malloc() Semicolon on this line should be a colon. Action: Change semicolon to a colon. [Ed recommendation: Accept Note this should be page 657] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 62 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 245) [DST-161] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Reject, we do not feel it appropriate to change the (admittedly bad) wording from C99. _____________________________________________________________________________ Page: 652 Line: 5357 Section: btowc Problem: Is this function well-defined or not? (Based on the response to D3 ERN 83, one would have to conclude that it is not, but I believe that it is.) The bulk of the definition is in the RETURN VALUE section, but as written this page is confusing, because it seems to be a logical determination, solely. >From last time: > 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: (A slightly different action.) Continue the sentence at 5157: ... and returns either an indication that it is not, or the corresponding wide character, as detailed in RETURN VALUE below. _____________________________________________________________________________ Objection Enhancement Request Number 63 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 319) [DWC-792] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 665 Line: 5757 Section: catgets Problem: (catgets(): errors) Recent postings on various security aliases have identified a security hole that can be exploited by replacing system message catalogs with user supplied message catalogs using NLSPATH when invoking a setuid utility. This issue is being discussed by a group of security experts at The Open Group (since this text came from SUSv2). When they complete their discussions, I expect they will forward a resolution to The Open Group's Base Working group to fix SUSv2. This is being submitted here now to be sure that an objection is on the books for the revision. If the security experts addressing this issue alter this proposal, I will submit the replacement fix at the draft 4 ballot resolution meeting in Austin. There are related fixes in other parts of my ballot to address changes needed to the description of NLSPATH in XBD6d4 and catopen() in XSH6d4. Action: Add the following new error to the ERRORS section after P665, L5757: [EBADMSG] The message identified by set_id and msg_id in the specified message catalog did not satisfy implementation-defined security criteria. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 64 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 320) [DWC-793] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 667 Line: 5796 Section: catopen Problem: (catopen(): description) Recent postings on various security aliases have identified a security hole that can be exploited by replacing system message catalogs with user supplied message catalogs using NLSPATH when invoking a setuid utility. This issue is being discussed by a group of security experts at The Open Group (since this text came from SUSv2). When they complete their discussions, I expect they will forward a resolution to The Open Group's Base Working group to fix SUSv2. This is being submitted here now to be sure that an objection is on the books for the revision. If the security experts addressing this issue alter this proposal, I will submit the replacement fix at the draft 4 ballot resolution meeting in Austin. There are related fixes in other parts of my ballot to address changes needed to the description of NLSPATH in XBD6d4 and catgets() in XSH6d4. Action: Add a new sentence on P667, L5796 before the 5th sentence (starting with "If NLSPATH does not exist") in the paragraph: If NLSPATH exists in the environment when the process starts, then if the process has appropriate privileges, the behavior of catopen() shall be undefined. ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 65 ajosey@opengroup.org Bug in XSHd4 (rdvk# 87) {tog.sep4.4} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE by ERN 53 _____________________________________________________________________________ Page: 669 Line: 5882 Section: cbrt Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions (previously this was an XSI man page) Action: XSI shade line 5882 and 5885 _____________________________________________________________________________ comment Enhancement Request Number 66 prindle@voicenet.com Bug in XSHd4 (rdvk# 58) [prindle.xsh-23] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_53 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 669 Line: 5882,5885 Section: cbrt() Problem: Other C functions mark the error condition associated with passing NaN in as a C extension. I suspect this one should be too. Action: Shade these lines and mark CX. _____________________________________________________________________________ Objection Enhancement Request Number 67 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 232) [DST-97] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: do action 1 only. App Usage becomes "None". _____________________________________________________________________________ Page: 683 Line: 6267 Section: chdir Problem: Two problems here. First the same text appears at 6271. Second, there's no normative text about chdir taking NULL as a special case that I can find. I speculate that this text belongs to getcwd, but I'm unsure how it got here. Action: 1) Remove both copies of the text. 2) Put one copy at 16334 (getcwd Application Usage). _____________________________________________________________________________ Objection Enhancement Request Number 68 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 246) [DST-162] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move 6315 - 6321 as indicated to XBD General concepts. at line 6314, add (XSI shaded) I_SVTX to list of bits. _____________________________________________________________________________ Page: 684 Line: 6315 Section: chmod Problem: This text does not belong here any more than a description of the meaning of S_IRUSR does. Move this text to File Access Permissions (4.1) as it's really about that. (This discussion really affects open() and rename() far more than it affects chmod.) (I remember something about adding a definition in this regard, but I'm unable to find either the Reviewer's Note or the new definition; it would help.) Action: If it doesn't fit in 4.3, then add a new section: 4.5a Directory Protection. Move text to here (and renumber sections) _____________________________________________________________________________ editorial Enhancement Request Number 69 prindle@voicenet.com Bug in XSHd4 (rdvk# 59) [prindle.xsh-24] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 694 Line: 6643 Section: clock() Problem: Gratuitous change of ISO C99 wording. The phrase "beginning of a... time" is poor, as a time is a unary object. The original term "era" was correct because it denoted a period of time. Action: Change "implementation-defined time" back to "implementation-defined era". ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 70 Michael.Kavanaugh@oracle.com Bug in XSHd4 clock_nanosleep (rdvk# 15) {2} Wed, 16 Aug 2000 01:29:20 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 700 Line: 6845 Section: clock_nanosleep Problem: clock_nanosleep() should be labelled as "(REALTIME)" Action: Add "(REALTIME)" to end of page 700 line 6845 [Ed recommendation: Accept as marked.Mark this ADVANCED REALTIME, it cannot be REALTIME since this is not part of the Realtime Option Group ] _____________________________________________________________________________ objection Enhancement Request Number 71 ajosey@opengroup.org Bug in XSHd4 close (rdvk# 227) {tog.sep23.1} Sat, 23 Sep 2000 17:49:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 704 Line: 7009-7012 Section: close Problem: The text on these lines is incorrectly XSR shaded and should be XSI, since pseudo-terminals need not be implemented using STREAMS. This also occurs on the open() man page , the fixes are noted below. Action: On the close() man page, p 704, change the shading on lines 7009-7012 to XSI The XSR shading should remain on lines 7013-7014 On the open() man page, p1353, lines 27455-27457 should have the XSR shading changed to XSI and on the open() man page, p1354, line 27501 should have the XSR shading changed to XSI [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 72 Joseph S. Myers BUG in XSHd4 (rdvk# 30) Wed, 23 Aug 2000 02:31:21 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The message body is generated from the message and following arguments in the same manner as if these were arguments to printf(), except that the additional conversion specifier %m shall be recognized; it shall convert no arguments, shall cause the output of the error message string associated with the value of errno on entry to syslog() and may be mixed with argument specifications of the "%n$" form. If a complete conversion specification with the 'm' conversion character is not just "%m", the behavior is undefined. A trailing may be added if needed. _____________________________________________________________________________ Page: 710 Line: 7177-7180 Section: closelog Problem: The specification of handling of %m in syslog() is unclear. There are two different plausible interpretations, both of which are in current use: 1) %m is treated as a format conversion specification that converts no arguments and expands to strerror(errno) (using the value of errno on entry to syslog()). 2) %m in the format string is converted to the current error string, irrespective of conversion specifications in the format string, before the format string is passed to printf() (or equivalent). (While some implementations may vary this by sending parts of the string to printf() separately, and inbetween such calls outputting the expansions of %m, such an implementation has problems with correctly handling %n and %$ formats.) For example, with interpretation (1), "%%m" is a valid format string that does not include a "%m" conversion specification; but with interpretation (2) it is invalid, or might be valid if the implementation is known to return a standard error string beginning with a character that is a valid conversion specifier. Action: I don't think interpretation (2) can readily have a precise definition attached to it. A minimal change addressing the problem here would be: Line 7180, at end add "If message contains %%m, the behavior is undefined.". My preferred solution would be to follow interpretaion 1: Replace lines 7177-7180 by: The message body is generated from the message and following arguments in the same manner as if these were arguments to printf(), except that the additional conversion specifier %m shall be recognized; it shall convert no arguments, shall cause the output of the error message string associated with the value of errno on entry to syslog() and may be mixed with argument specifications of the "%n$" form. If a complete conversion specification with the 'm' conversion character is not just "%m", the behavior is undefined. A trailing character is added if needed. _____________________________________________________________________________ Editorial Enhancement Request Number 73 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 270) [DWC-666] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 710 Line: 7180 Section: closelog Problem: (closelog(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P710, L7180 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 74 prindle@voicenet.com Bug in XSHd4 (rdvk# 61) [prindle.xsh-26] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 721 Line: 7562 Section: copysign() Problem: Who made this up? Clearly C99 says no such thing. It is largely silent on numbers with the value +/- Inf. Action: To be consistent with its definition, either remove this line or change it to "If x is +/- Inf, these functions shall return x (with the sign of y)." [Ed recommendation: Delete line 7562, also delete lines 7527-7575 , this rationale is not accurate ] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 75 prindle@voicenet.com Bug in XSHd4 (rdvk# 60) [prindle.xsh-25] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A specific action to remove one tiny source of conflict: On line 7563, replace "NaN shall be returned" with "NaN (with the sign of y) shall be returned". The rest of this will be covered by actions on ERN 53 _____________________________________________________________________________ Page: 721 Line: 7563-7565 Section: copysign() Problem: In general, there is mixed consistency in the RETURN VALUE and ERRORS sections of all the ISO C functions with respect to EDOM and/or NaN. Here, the possibility of EDOM being set into errno is allowed (not as extension); likewise with cbrt(). On the next page (cos()) the setting of errno to EDOM is considered an XSI extension. Still another variation are functions like ccos(), which do not address EDOM at all, even as an extension. Yet, C99 has precisely one and only one statement about EDOM: "For all functions, a domain error occurs if an input argument is outside the domain over which the mathematical function is defined. The description of each function lists any required domain errors; an implementation may define additional domain errors, provided that such errors are consistent with the mathematical definition of the function. On a domain error, the function returns an implementation-defined value;" Note that in this function, the function value IS defined when x is NaN, so technically this is not a domain error - the function does not return an implementation-defined value, but rather a well-defined value. None of cos(), ccos(), cbrt(), or copysign() list any required domain errors in their descriptions. As another example, exp() and exp2() are treated inconsistently WRT NaN and EDOM as extensions. There are numerous other such inconsistencies. Action: What we need here are 2 things: a) A general policy regarding ISO C error handling WRT NaN handline and EDOM issues (not necessarily, but possibly related). This would have to be something agreed upon between the C Std community and the POSIX community. b) A project to examine all the C functions (largely only the mathematical ones) and determine where the general policy applies and where there are exceptions (aren't there always?) c) Application of the results of this project to the document. It would be nice if during this review cycle, someone from the ISO C community could suggest how this issue could be fixed consistently, but I doubt that is going to happen. Instead, what I'm afraid we'll end up with is a standard that conflicts with ISO C over these issues. A specific action to remove one tiny source of conflict: On line 7563, replace "NaN shall be returned" with "NaN (with the sign of y) shall be returned". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 76 ajosey@opengroup.org Bug in XSHd4 (rdvk# 86) {tog.sep4.5} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 721 Line: 7563 Section: copysign Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 7563 and 7566 _____________________________________________________________________________ Comment Enhancement Request Number 77 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 233) [DST-98] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_4 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 729 Line: 7783 Section: creat Problem: Legacy or Obsolescent, if possible. (Even Dennis Ritchie isn't completely happy with this interface; he'd at least spell it with an 'e'). More seriously, it shouldn't be used in new applications, venerable though it is. Action: Mark, one way or another. _____________________________________________________________________________ Editorial Enhancement Request Number 78 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 247) [DST-163] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 738 Line: 8064 Section: ctermid Problem: Duplicate text; 2d sentence at 8064 and 8102. Action: Delete 8102 [Ed recommendation:Accept] _____________________________________________________________________________ Objection Enhancement Request Number 79 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 248) [DST-164] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team notes the change request but finds that this change is out of scope. _____________________________________________________________________________ Page: 752 Line: 8515 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 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). _____________________________________________________________________________ Editorial Enhancement Request Number 80 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 234) [DST-99] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Given that the paragraphs are numbered from 1 to 5, reorder them into 3,2,4,1,5. DT will supply other suggested orderings _____________________________________________________________________________ Page: 769 Line: 9035 Section: endgrent Problem: As I've observed before, I really believe groups of functions like this should be alphabetized on the "primary" function (or at least *a* primary function) rather than a bookkeeping one like the end... functions. I've resigned myself to losing that battle (but if there are allies out there....). However, doing the same alphabetzation within a single page makes for an unreadable mess. It takes a lot of extra reading to make sense of something that's fairly simple because it's presented in such an obscure order. Action: Given that the paragraphs are numbered from 1 to 5, reorder them into 3,2,4,1,5. Similarly for all the other functions that have been alphabetized into ununderstandability. (Certainly all the end... functions.) (I'll be happy to provide the other reorderings later.) [Ed recommendation: NONE Needs discussion] _____________________________________________________________________________ Objection Enhancement Request Number 81 adjg@eng.sun.com Bug in XSHd4 (rdvk# 150) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 771 Line: 9086,9090,9103-6,9124-6,9128 Section: endhostent Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Delete lines 9090,9103-6,9124-6. Delete freehostent() from 9086. Delete the sentence "Applications shall not call freehostent() for this area" from 9128. _____________________________________________________________________________ objection Enhancement Request Number 82 prindle@voicenet.com Bug in XSHd4 (rdvk# 62) [prindle.xsh-27] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_81 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 771 Line: 9090 Section: endhostent() Problem: The function freehostent() is seriously misplaced being on this page. It is never used in conjunction with any of the other functions on this page, but only with functions on the gethostbyaddr() page. It's function is to form the deallocation part of getipnodebyaddr()/getipnodebyname(), which in turn are thread-safe replacements for gethostbyname()/gethostbyaddr(). All of this is described on the gethostbyaddr() page, so this belongs there. Action: Move freehostent(), including its description, to the gethostbyaddr() page. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 83 adjg@eng.sun.com Bug in XSHd4 (rdvk# 151) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 771 Line: 9111 Section: endhostent Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), getipnodebyname(). _____________________________________________________________________________ Objection Enhancement Request Number 84 adjg@eng.sun.com Bug in XSHd4 (rdvk# 152) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 772 Line: 9134 Section: endhostent Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), getipnodebyname(). _____________________________________________________________________________ comment Enhancement Request Number 85 prindle@voicenet.com Bug in XSHd4 (rdvk# 64) [prindle.xsh-29] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 773 Line: 9154 Section: endnetent() Problem: See also page 773 line 9157-9158 See also page 773 line 9159-9160 See also page 775 line 9207-9208 See also page 775 line 9210-9211 See also page 775 line 9212-9213 See also page 779 line 9329-9330 See also page 779 line 9333 See also page 779 line 9337 See also page 771 line 9107-9109 See also page 1013 line 17048 See also page 1013 line 17052 All these functions do basically the same thing. Yet some say "opening a connection to the database if necessary" and some say "opening and closing a connection to the database as necessary". Well, which is it? If no connection is open, one is opened - that is clear; but if it is opened, is it closed? That is terribly inconsistent among these lines, and even between essentially parallel functions. Action: Pick one (whichever is existing practice), and stick with it in these 12 places. [Ed recommendation: Accept as marked: change phrasing on page 773, line 9154,9159 page 775, line 9207,9211 page 779, line 9329,9333 page 1013, line 17048,17052 to "opening and closing a connection to the database as necessary"] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 86 prindle@voicenet.com Bug in XSHd4 (rdvk# 65) [prindle.xsh-30] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. ERN 53 will also make changes here. _____________________________________________________________________________ Page: 786 Line: 9483-9489 Section: erf() Problem: These functions are incorrectly shaded and identified as XSI functionality. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). [Ed recommendation: Accept as marked. Add the standard ISO C disclaimer block. XSI shade 9500 If x is NaN, NaN shall be returned and errno may be set to [EDOM].] XSI shade line 9507 [EDOM] The value of x is NaN. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 87 ajosey@opengroup.org Bug in XSHd4 erf (rdvk# 10) {tog.aug14.1} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_86 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 786 Line: 9483 Section: erf Problem: The erf family of functions are required by the C standard and should not be XSI shaded Action: Remove the XSI shading from the complete synopsis block. Add to CH, The erf() and erfc() functions are no longer XSI shaded. _____________________________________________________________________________ editorial Enhancement Request Number 88 ajosey@rdg.opengroup.org BUG in XSHd4 exec (rdvk# 314) {aj.tog.26sep.4} Tue, 26 Sep 2000 15:31:38 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 790 Line: 9601 Section: exec Problem: wording Action: Change "The exec functions" to "The exec family of functions" [Ed recommendation: Accept] _____________________________________________________________________________ Objection Enhancement Request Number 89 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 249) [DST-165] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 790 Line: 9629 Section: exec Problem: Look first at the definition of EINVAL on 7964. It specifically allows the system to say "executable, but not mine". The text at 9627 says "if not a valid executable object". The file it is allowed to reject on 7964 is still a valid executable object (arguably the word valid can be stretched, but why bother with the risk?). (See D3 ERN 160) Action: "executable object," -> "executable object, and the system does not recognize it as something that cannot be executed (and thus returns EINVAL)," _____________________________________________________________________________ Comment Enhancement Request Number 90 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 235) [DST-100] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 792 Line: 9710 Section: exec Problem: I don't know enough about the tracing stuff to be sure what the intent was, but this use of "shall not" is just odd enough that it deserves clarification. If it really is intended as a prohibition of the inheritance then it's worth a note. If the intent was "need not" (that is, we're not requireing it), then change it to be that. Action: Either add a note somewhere (preferably by a nice turn of phrase here) indicating that the prohibition is intentional, or change to "need not". _____________________________________________________________________________ editorial Enhancement Request Number 91 ajosey@rdg.opengroup.org BUG in XSHd4 exec (rdvk# 315) {aj.tog.26sep.5} Tue, 26 Sep 2000 15:31:38 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 793 Line: 9739 Section: exec Problem: shallification Action: Change "results in all" to "shall result in all" [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 92 ajosey@opengroup.org Bug in XSHd4 exec (rdvk# 136) {tog.sep13.1} Wed, 13 Sep 2000 10:17:17 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 794 Line: 9796 Section: exec Problem: The NULL argument should be (char *)0 (this is a comment as this is an informative example) Action: Change NULL to "(char *)0" on line 9796,9802,9811, 9813,9816,9825,9834 [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 93 Clive D.W. Feather ax.com> (rdvk# 137) [CDWF 36] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10029 Section: exit() Problem: The function _Exit() is in , not . Action: Move this line to above line 10028. _____________________________________________________________________________ objection Enhancement Request Number 94 Clive D.W. Feather ax.com> (rdvk# 138) [CDWF 37] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10032 Section: exit() Problem: The _Exit() function is also aligned with C99. Action: Change "for the exit() function" to "for the exit() and _Exit() functions". [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 95 Clive D.W. Feather ax.com> (rdvk# 139) [CDWF 38] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10042 Section: exit() Problem: Effects are not undefined, behaviour is. Action: Change "the effects are undefined" to "the behaviour is undefined". [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 96 prindle@voicenet.com Bug in XSHd4 (rdvk# 68) [prindle.xsh-33] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10043-10044 Section: exit() Problem: The text that is shaded and marked CX on these lines does not appear to be an extension to ISO C. However, the exact ISO C semantics are not exactly what is shown here. Action: Remove shading and replace the shaded text with. The exit() function then flushes all open streams with unwritten buffered data, closes all open streams, and removes all files created by tmpfile(). Finally control is returned to the host environment as described below. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 97 Clive D.W. Feather ax.com> (rdvk# 140) [CDWF 39] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_96 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10043-4 Section: exit() Problem: The behaviour in the first sentence ("The exit() ... tmpfile().") is defined in the C Standard and so should not have CX shading. Action: Remove the shading. [Ed recommendation: DUP of prindle.xsh-33] _____________________________________________________________________________ objection Enhancement Request Number 98 Clive D.W. Feather ax.com> (rdvk# 142) [CDWF 41] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10044-10047,10049-10050 Section: exit() Problem: This is a three part problem that can best be solved with one mass change. Firstly, the concept of "control is returned to the host environment" is taken directly from the C Standard. It is *not* appropriate here, since what it actually means on a Unix system is "terminate the process in the normal way". Secondly, the stuff about the values of status applies to all three functions, not just exit(). Thirdly, the behaviour of _Exit() and _exit() is incompletely described. Action: Delete from "Finally" on line 10044 to the end of line 10047, replacing it with the text: Finally the calling process is terminated with the consequences described below. Insert a new paragraph before line 10049 (it would be acceptable to merge this with the paragraph at line 10048): The _Exit() and _exit() functions shall not call functions registered with atexit() nor any registered signal handlers. Whether open streams are flushed, open streams are closed, or temporary files are removed is implementation-defined. Finally the calling process is terminated with the consequences described below. [The text "and _exit()" should be CX shaded; the rest should be left unshaded.] Add a new paragraph before line 10035: The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the bottom 8 bits (that is, status & 255) shall be available to a waiting parent process. [The text from "or any" onwards should be CX shaded; the previous part should be left unshaded.] _____________________________________________________________________________ objection Enhancement Request Number 99 prindle@voicenet.com Bug in XSHd4 (rdvk# 69) [prindle.xsh-34] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_98 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10048 Section: exit() Problem: This is not sufficient to relate the ISO C semantics of _Exit(), since all the semantics that follow (with respect to _Exit(),_exit(), and exit()) are CX, so there is no normative definition of _Exit() semantics. Action: Replace this line with the following, not shaded except for the words "bsd_signal(), or sigaction()" and "or _exit()" [shaded CX]: The _Exit() or _exit() function causes 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(), bsd_signal(), or sigaction() function are 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-defined. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 100 Clive D.W. Feather ax.com> (rdvk# 141) [CDWF 40] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10048 Section: exit() Problem: The _exit() function is not in C, so this line should be CX shaded. Action: Make it so. [Ed recommendation: Accept [but note that some of the other changes may change the wording here]] _____________________________________________________________________________ objection Enhancement Request Number 101 Clive D.W. Feather ax.com> (rdvk# 143) [CDWF 42] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10049-10050 Section: exit() Problem: Termination is a requirement of the C Standard. The CX shading should be restricted to "_exit()," and "with the following consequences:", leaving the rest unshaded. Action: Make it so. [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 102 Clive D.W. Feather ax.com> (rdvk# 144) [CDWF 43] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 801 Line: 10053 Section: exit() Problem: The XSI shading on line 10054 should be extended back to the words "and has". Action: Make it so, also on line 10058. [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 103 Clive D.W. Feather ax.com> (rdvk# 145) [CDWF 44] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "and has not set its SA_NOCLDWAIT flag, or set SIGCHLD to SIG_IGN" on XSH6 draft 4, P801, L10058-10059 to "and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN". _____________________________________________________________________________ Page: 801 Line: 10054,10059 Section: exit() Problem: The wording on these two lines *appears* to say the same thing in different words. The latter wording is ambiguous: it could be parsed either as: has not (set its SA_NOCLDWAIT flag or set SIGCHLD to SIG_IGN) or as: has (not set its SA_NOCLDWAIT flag) or (set SIGCHLD to SIG_IGN) The existence of the bullet point at line 10066 implies the former, but it's not very clear. Action: Change the shaded wording on line 10059 to that used on line 10054. _____________________________________________________________________________ objection Enhancement Request Number 104 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 313) {aj.tog.26sep.7} Tue, 26 Sep 2000 15:55:53 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This was the result of a wording addition in D3 _____________________________________________________________________________ Page: 802 Line: 10071 Section: exit Problem: This seems unnecessary wording given the sentence before, its also not in .1-1996 Action: Delete "That is, these processes are inherited by a special system process". _____________________________________________________________________________ editorial Enhancement Request Number 105 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 312) {aj.tog.26sep.6} Tue, 26 Sep 2000 15:55:53 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 802 Line: 10071 Section: exit Problem: wording - shallification Action: Change "processes is set to the process ID of an implementation-defined system process" to "processes shall be set to the process ID of an implementation-defined system process" [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 106 Clive D.W. Feather ax.com> (rdvk# 146) [CDWF 45] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The review team disagrees with the problem statement because both actions are distinct, both are needed, the wording is correct. _____________________________________________________________________________ Page: 802 Line: 10077,10082 Section: exit() Problem: It is not clear to me whether the situations on lines 10077 and 10081 are mutually exclusive. If they are, you can ignore this comment. If they can both happen, then it is unclear whether the two SIGHUP signals need to remain distinct or whether they can or must be merged. Action: I don't know the position well enough to suggest wording, but find some wording that explains how the two SIGHUPs are related. _____________________________________________________________________________ editorial Enhancement Request Number 107 prindle@voicenet.com Bug in XSHd4 (rdvk# 70) [prindle.xsh-35] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 802 Line: 10103-10106 Section: exit() Problem: This paragraph should be bulleted and indented like its predecessors. It is one of the enumerated CX consequences of all 3 functions. Action: Indent and bullet paragraph. Retain shading and margin code as is. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 108 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 236) [DST-101] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 803 Line: 10117 Section: exit Problem: "different" than what? It looks as if this text was placeed out of context at some point. This is as it appears in the -1990 standard, so that move was a LONG time ago. Action: I don't see any loss in just removing "different". [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 109 Clive D.W. Feather ax.com> (rdvk# 147) [CDWF 46] Thu, 14 Sep 2000 16:38:27 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the change recommended below, also there is an action on Ulrich to provide words for the c99 utility _____________________________________________________________________________ Page: 804 Line: 10151-10153 Section: exit() Problem: Reaching the end of the main() function is not equivalent to using exit(), and the bit about "with an unspecified value" is wrong. The actual wording of C99 is: If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;[*] reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified. [*] In accordance with 6.2.4, the lifetimes of objects with automatic storage duration declared in main will have ended in the former case, even where they would not have in the latter. Action: Change this wording to: As required by the ISO C standard, using return from main() has the same behaviour (other than with respect to language scope issues) as calling exit() with the returned value. Reaching the end of the main() has the same behaviour as calling exit(0). [Does XSI require main() to be an int ? I don't have it within reach. If not, further words will be needed to cover the case of other types.] _____________________________________________________________________________ Objection Enhancement Request Number 110 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 238) [DST-103] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 806 Line: 10250 Section: exp Problem: It's not the "exponent" of x, it's the "exponential function" of x. Action: exponent -> exponential function. [Ed recommendation: Accept as marked. Replace with text based on ISO C99: "These functions shall compute the base-e exponential of x." (e in italics, x in italics)] _____________________________________________________________________________ Objection Enhancement Request Number 111 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 237) [DST-102] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 808 Line: 10299 Section: exp2 Problem: Two problems; wrong function name, wrong function definition. Action: Replace line with: These functions shall compute the base 2 exponential function of x, defined as 2x. (See line 10303). [Ed recommendation: Accept as marked: replace line with "These functions shall compute the base-2 exponential of x." ] _____________________________________________________________________________ objection Enhancement Request Number 112 ajosey@opengroup.org Bug in XSHd4 (rdvk# 89) {tog.sep4.2} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 808 Line: 10308,10313 Section: exp2 Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions. Action: XSI shade line 10308 and 10313 _____________________________________________________________________________ objection Enhancement Request Number 113 ajosey@opengroup.org Bug in XSHd4 (rdvk# 85) {tog.sep4.6} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 810 Line: 10338 Section: expm1 Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 10338 and 10344 _____________________________________________________________________________ editorial Enhancement Request Number 114 ajosey@opengroup.org Bug in XSHd4 expm1 (rdvk# 4) {tog.aug14.2} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 810 Line: 10365 Section: expm1 Problem: Missing change history Action: Add to CH, The expm1 function is no longer XSI shaded. [Ed recommendation: Accept as marked. As above but add the ISO C Disclaimer block] _____________________________________________________________________________ Objection Enhancement Request Number 115 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 250) [DST-166] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add text before 10511, A conforming application can obtain a file descriptor for a file of type directory using open(), provided that the file status flags and access modes do not contain O_WRONLY or O_RDWR. _____________________________________________________________________________ Page: 816 Line: 10509 Section: fchdir Problem: D3 ERN 494 Either provide a description of how a conforming or strictly conforming application can use this function, or delete it. I don't believe that that's possible to do the former. (The function serves no purpose in the standard if no portable application has a use for it.) Action: Delete function. _____________________________________________________________________________ objection Enhancement Request Number 116 ajosey@opengroup.org Bug in XSHd4 (rdvk# 84) {tog.sep4.7} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 834 Line: 11146 Section: fdim Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 11146 and 11151 _____________________________________________________________________________ objection Enhancement Request Number 117 prindle@voicenet.com Bug in XSHd4 (rdvk# 99) [prindle.xsh-36] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 835 Line: 11182,11211,11230 Section: fdopen() Problem: Reference to the "type" argument. There is no such argument. Action: Change all "type" to "mode". [note that it was "type" in POSIX, this change apparently causing the inconsistency] [Ed recommendation: Accept as marked, as above, but not to line 11230 which is ok as is] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 118 prindle@voicenet.com Bug in XSHd4 (rdvk# 100) [prindle.xsh-37] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 836 Line: 11212-11214 Section: fdopen() Problem: This sentence of rationale is contradictory to the text as modified in this revision. Action: Change "There is no need... 200x." to "The mode argument formats that include a b are allowed for consistency with the ISO C function fopen(). The b has no effect on the resulting stream." _____________________________________________________________________________ Objection Enhancement Request Number 119 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 239) [DST-104] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is from a base document (c99) and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 841 Line: 11363 Section: fesetround Problem: Huh? Is this a function of the input macro alone, or is it a function of the actual hardware. It seems to say one, then the other. Is the implication that these functions shall not fail? (Yes, I see that only supported modes are supposed to be defined, but what if the user passes in (say) O_RDWR.) Action: How about: The fesetround() function shall return a zero value if the rounding direction specified as the argument (which shall be a rounding direction macro defined in ) could be established. (Note that there's a shall on the application here that makes the implementation's life a bit easier, in that if the application doesn't follow the rules, the implementation isn't required to try to diagnose the error anyway.) _____________________________________________________________________________ comment Enhancement Request Number 120 prindle@voicenet.com Bug in XSHd4 (rdvk# 102) [prindle.xsh-39] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because our specification is not a hosted environment _____________________________________________________________________________ Page: 853 Line: 11639 Section: fflush() Problem: The fflush() function is rather more qualified in ISO C than it is here. Action: Change "for that stream" to "for that stream to be delivered to the host environment". [I don't know quite what that means, but that's what it says. I suspect it refers to control bytes in the stream that are unique to the implementation and not anything written explicitly by the application would not be written to the file, whereas the remaining bytes are those to be delivered to the host environment (i.e. real user data).] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 121 prindle@voicenet.com Bug in XSHd4 (rdvk# 105) [prindle.xsh-42] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN 130 _____________________________________________________________________________ Page: 857 Line: 11761-11777 Section: fgetc() Problem: See also page 862 line 11898-11900 section fgets(). See also page 910 line 13637-13641 section fputc(). See also page 912 line 13720 section fputs(). See also page 932-936 line 14322-14503 section fscanf(). See also page 898-903 line 13133-13379 section fprintf(). The change of terminology from the ISO C terminology (character) to the POSIX terminology (byte) is not shaded as a deviation from ISO C. Action: Shade the word byte in each place, and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 122 prindle@voicenet.com Bug in XSHd4 (rdvk# 103) [prindle.xsh-40] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 857 Line: 11765 Section: fgetc() Problem: The word "character" on this line (in the context "next character") should be "byte", to match the "next byte" later in the line. Action: Change "character" to "byte". ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 123 prindle@voicenet.com Bug in XSHd4 (rdvk# 104) [prindle.xsh-41] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 857 Line: 11765 Section: fgetc() Problem: The parenthesized "(if present)" is redundant. It is also not in ISO C. Action: Remove it. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 124 jeffcope@microsoft.com (rdvk# 400) [Copeland-xsh-1] Tue, 26 Sep 2000 11:34:36 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 857 Line: 11765 Section: fgetc() [Annotation to [prindle.xsh-40]] Problem: The word "character" on this line (in the context "next character") should be "byte", to match the "next byte" later in the line. Prindle's proposed action: Change "character" to "byte". Action: In addition, emphasize the change by adding a sentence to the paragraph ending at line 11767, "Because fgetc() operates on bytes, reading a character consisting of multiple bytes [or "a multi-byte character"] may require multiple calls to fgetc()." _____________________________________________________________________________ objection Enhancement Request Number 125 prindle@voicenet.com Bug in XSHd4 (rdvk# 106) [prindle.xsh-43] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 860 Line: 11851 Section: fgetpos() Problem: This standard was updated to include the parse state of a stream in an object of type fpos_t, but this function was not updated to fetch it. Action: Change "current value of the file position" to "current values of the parse state (if any) and file position". ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 126 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 271) [DWC-667] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 862 Line: 11899 Section: fgets Problem: (fgets(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P862, L11899 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 127 prindle@voicenet.com Bug in XSHd4 (rdvk# 107) [prindle.xsh-44] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_126 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 862 Line: 11899 Section: fgets() Problem: Shouldn't " character" really be " byte" to conform to the change of terminology? Action: Change "character" to "byte". _____________________________________________________________________________ comment Enhancement Request Number 128 prindle@voicenet.com Bug in XSHd4 (rdvk# 108) [prindle.xsh-45] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because See ERN 130 _____________________________________________________________________________ Page: 864 Line: 11951-11962 Section: fgetwc() Problem: See also page 866 line 12022-12024 function fgetws() See also page 914 line 13774-13778 function fputwc() See also page 916 line 13848-13850 function fputws() See also page 932-936 line 14322-14503 section fscanf(). See also page 898-903 line 13133-13379 section fprintf(). The change of terminology from the ISO C terminology (wide character) to the POSIX terminology (character) is not shaded as a deviation from ISO C. Action: Shade the word character in each place, and margin code CX. _____________________________________________________________________________ comment Enhancement Request Number 129 jeffcope@microsoft.com (rdvk# 401) [Copeland-xsh-1] Tue, 26 Sep 2000 11:34:36 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because See ERN 130 _____________________________________________________________________________ Page: 864 Line: 11951-11962 Section: fgetwc() [Annotation to [prindle.xsh-45]] Problem: See also page 866 line 12022-12024 function fgetws() See also page 914 line 13774-13778 function fputwc() See also page 916 line 13848-13850 function fputws() See also page 932-936 line 14322-14503 section fscanf(). See also page 898-903 line 13133-13379 section fprintf(). Frank Prindle says, "The change of terminology from the ISO C terminology (wide character) to the POSIX terminology (character) is not shaded as a deviation from ISO C." Solution: A better change is to retain the ISO terminology, but change "wide character" to "(wide) character". We're already (mostly) clear on the byte/character distinction, but we need to emphasize which we're talking about here, namely that these interfaces return wint_t data types, not bytes or multi-byte characters which would then be translated by the application into wchar_t's with the mbtowc() family of interfaces. _____________________________________________________________________________ comment Enhancement Request Number 130 Sandra O'donnel Bug in XSHd4 (rdvk# 188) [compaq-smo-001] Thu, 21 Sep 2000 10:53:15 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 864 Line: 11951-11962 Section: fgetwc() Problem: I disagree with Frank Prindle's recommendation to shade the term "character" in the descriptions of fgetwc() and other similar functions, and with Jeff Copeland's alternate suggestion to use the term "(wide) character". The current wording on lines 11951-11952 is: "The fgetwc() function shall obtain the next character (if present) from the input stream pointed to by stream, convert that to the corresponding wide-character code, and advance the associated file position indicator for the stream (if defined)." Using Jeff's recommendation, the existing "...the next character" would become "...the existing (wide) character". Notice however, that the second phrase in the existing text already refers to wide-character codes, so the full sentence would read "...the next (wide) character (if present) from the input stream pointed to by stream, convert that to the corresponding wide-character code..." There is no need to refer to wide characters the first time; the second phrase already does so. Using Frank's recommendation, only shading would be added to word "character." Frank's rationale is to point out a deviation from the ISO C "wide character" terminology to the POSIX "character." I'm not arguing that this is a deviation, but rather that using "wide character" in this instance is wrong, even if ISO C does it. The description is trying to explain that fgetwc() gets an abstract thing called a character and converts it to a wide-character code. When fgetwc() gets the character, it isn't yet a wide character, which is why I believe both Frank and Jeff's recommendations (and ISO C) are wrong. A wide character is a typedef with specific semantics for a given implementation; a character is an abstract thing that is separate from size and storage definitions. An "A" is a character, regardless of whether is is represented within a single 8-bit char data type or within a 32-bit wchar_t type. Action: Because the cited usage of "character" in fgetwc() and related functions is not as a wide character, the text should remain as is. _____________________________________________________________________________ Editorial Enhancement Request Number 131 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 272) [DWC-668] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 866 Line: 12024 Section: fgetws Problem: (fgetws(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P866, L12024 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 132 ajosey@opengroup.org Bug in XSHd4 (rdvk# 83) {tog.sep4.8} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 873 Line: 12230 Section: fma Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 12230 and 12233 _____________________________________________________________________________ objection Enhancement Request Number 133 ajosey@opengroup.org Bug in XSHd4 (rdvk# 82) {tog.sep4.9} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 874 Line: 12269 Section: fmax Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 12269 and 12272 _____________________________________________________________________________ objection Enhancement Request Number 134 ajosey@opengroup.org Bug in XSHd4 (rdvk# 81) {tog.sep4.10} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE See ERN 53 _____________________________________________________________________________ Page: 875 Line: 12304 Section: fmin Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 12304 and 12307 _____________________________________________________________________________ objection Enhancement Request Number 135 prindle@voicenet.com Bug in XSHd4 (rdvk# 109) [prindle.xsh-46] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 883 Line: 12578,12581 Section: fopen() Problem: These lines enumerate certain values for mode, but do not include the b forms. Action: Change "If mode is w, a, w+, or a+" to "If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b". Change "If mode is w or w+" to "If mode is w, wb, w+, wb+, or w+b". [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 136 prindle@voicenet.com Bug in XSHd4 (rdvk# 110) [prindle.xsh-47] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 884 Line: 12587-12588 Section: fopen() Problem: ISO C does not acknowledge the existence of either off_t or an open file description. Action: Shade these lines and margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 137 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 316) {aj.tog.26sep.1} Tue, 26 Sep 2000 15:19:02 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 887 Line: 12725 Section: fork Problem: shallification Action: Change "does not inherit" to "shall not inherit" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 138 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 317) {aj.tog.26sep.2} Tue, 26 Sep 2000 15:19:02 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 888 Line: 12743 Section: fork Problem: shallification Action: Change "process contains a" to "process shall contain a" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 139 prindle@voicenet.com Bug in XSHd4 (rdvk# 111) [prindle.xsh-48] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 888 Line: 12758 Section: fork() Problem: The bullet on this line should not be shaded. Action: Remove shading on bullet. [Ed recommendation: Accept, the editors will fix ] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 140 prindle@voicenet.com Bug in XSHd4 (rdvk# 112) [prindle.xsh-49] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 888 Line: 12763-12768 Section: fork() Problem: This paragraph is clearly in conflict with the prior (1003.1-1996) version. The original makes no such assertion as found here in the second sentence. Also, use of "this volume of" won't work, because normative parts of the XBD volume also define process characteristics. Action: Restore the 1003.1-1996 text of this paragraph, appropriately reworded for this revision: All other process characteristics defined by IEEE Std. 1003.1-200x shall be the same in the parent and child processes. The inheritance of process characteristics not defined by IEEE Std. 1003.1-200x is unspecified by IEEE Std. 1003.1-200x. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 141 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 318) {aj.tog.26sep.3} Tue, 26 Sep 2000 15:19:02 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 888 Line: 12769 Section: fork Problem: shallification Action: Change "processes are capable" to "processes shall be capable" [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 142 prindle@voicenet.com Bug in XSHd4 (rdvk# 113) [prindle.xsh-50] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove shading and margin code on these paragraphs. Change first paragraph to: The snprintf() function is identical to sprintf() with the addition of the n argument, which states the size of the buffer referred to by s. If n is zero, nothing is written and s may be a null pointer. Otherwise, output bytes beyond the n-1st are discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. _____________________________________________________________________________ Page: 898 Line: 13135-13140 Section: fprintf() Problem: Neither the concept of snprintf() nor undefined results on overlap are extensions to ISO C, but the wording here needs some work. Action: Remove shading and margin code on these paragraphs. Change first paragraph to: **************************************************************************** The snprintf() function is identical to sprintf() with the addition of the n argument, which states the size of the buffer referred to by s. If n is zero, nothing is written and s may be a null pointer. Otherwise, output bytes beyond the n-1st are discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. **************************************************************************** Also note that the words "byte" above should be shaded and marked CX because of the change in terminology between ISO C and POSIX. _____________________________________________________________________________ objection Enhancement Request Number 143 Clive D.W. Feather BUG in XSId4 (rdvk# 13) [CDWF 34] Tue, 15 Aug 2000 09:04:42 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_142 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 898 Line: 13135-13138 Section: fprintf Problem: The snprintf() function is mandatory in C99, but these lines are XSI shaded. Action: Remove the XSI shading from these lines. _____________________________________________________________________________ objection Enhancement Request Number 144 Clive D.W. Feather BUG in XSId4 (rdvk# 14) [CDWF 35] Tue, 15 Aug 2000 09:04:42 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 898 Line: 13139-13140 Section: fprintf Problem: The rule concerning copying between overlapping objects comes straight from C99, but these lines are XSI shaded. Action: Remove the XSI shading from these lines. [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 145 Joseph S. Myers BUG in XSHd4 (rdvk# 18) Fri, 18 Aug 2000 21:15:47 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 899 Line: 13170 Section: fprintf Problem: In several places the fprintf specification is not aligned with C99 because of failure to include the new floating point conversion specifiers. The same problems occur with fwprintf. Action: Change "e, E, and f" to "a, A, e, E, f, and F". Also at page 899 line 13208-13209 section fprintf objection Change "e, E, f, g, or G" to "a, A, e, E, f, F, g, and G". page 900 line 13214 section fprintf objection Change "e, E, f, g, and G" to "a, A, e, E, f, F, g, and G". page 967 line 15491 section fwprintf objection Change "e, E, and f" to "a, A, e, E, f, and F". page 967 line 15530-15531 section fwprintf objection Change "e, E, f, g, or G" to "a, A, e, E, f, F, g, and G". page 968 line 15536 section fwprintf objection Change "e, E, f, g, and G" to "a, A, e, E, f, F, g, and G". _____________________________________________________________________________ comment Enhancement Request Number 146 Joseph S. Myers BUG in XSHd4 (rdvk# 1) Sat, 5 Aug 2000 00:59:37 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 899 Line: 13195-13197 Section: fprintf Problem: The decimal conversions for which the ' flag applies should include %F (added in C99) since they include %f. Action: Change "%f" to "%f, %F". _____________________________________________________________________________ Objection Enhancement Request Number 147 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 251) [DST-167] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use a consistent font (editor's choice) (only in fprint/fwprintf/fscanf/fwscanfi and file format notation) ACTION Donn Terry to assist in locating all places where printf conversion characters are used and need alternate representation (font) _____________________________________________________________________________ Page: 900 Line: 13221 Section: fprintf Problem: The characters 0 and # (etc.) above this point are literal characters included in a printf format. The characters hh, h and d and F and... below this point are literal characters included in a printf format. The first group is in Roman. The second group is italic. BOTH should be CW. Action: Fix, here and in the vicinity of line 15620. _____________________________________________________________________________ Objection Enhancement Request Number 148 adjg@eng.sun.com Bug in XSHd4 (rdvk# 159) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 925 Line: all Section: freehostent() Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Delete this page. _____________________________________________________________________________ Editorial Enhancement Request Number 149 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 273) [DWC-669] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 912 Line: 13747 Section: fputs Problem: (fputs(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P912, L13747 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 150 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 274) [DWC-670] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 916 Line: 13862 Section: fputws Problem: (fputws(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character." on P916, L13862 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 151 prindle@voicenet.com Bug in XSHd4 (rdvk# 116) [prindle.xsh-53] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 917 Line: 13886-13898 Section: fread() Problem: See also page 973 line 15747-15757 section fwrite() The term "member(s)" is used to refer to and individual item in an array. This is the incorrect term. Member refers to an item in a structure. Element refers to an item in an array. ISO C has it correct. Of course, ISO C also uses the variable name "nmemb" for the argument, very misleading; our nitems is better, though nobjects or nelements would have been even better. N.B.: Member is used correctly on 13919/15766, because here it is referring to the non-portability of strucure organization. Action: Change all occurences of "member" on these lines to "element". Likewise "members" -> "elements". [Ed recommendation: Accept. (lines are 13886-13898,15747-15757)] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 152 prindle@voicenet.com Bug in XSHd4 (rdvk# 114) [prindle.xsh-51] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 917 Line: 13887 Section: fread() Problem: See also page 973 line 15748 section fwrite() The last word "size" on this line is the name of an argument, and should be italicized. Action: Italicize the last "size". [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 153 prindle@voicenet.com Bug in XSHd4 (rdvk# 115) [prindle.xsh-52] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 917 Line: 13887-13888 Section: fread() Problem: See also page 973 line 15748-15749 section fwrite() This is from ISO C, and dictates an implementation. That is, an implementation of fread() MUST call fgetc(), size times and an implementation of fwrite() MUST call fputc(), size times. This is a strange requirement. Normally, I would expect to see this stated in "as if" form, allowing the implementation more freedom. I also doubt this requirement is testable. Action: Change: "size calls are made to the fgetc() function and the results stored" to "the function shall behave as if size calls were made to the fgetc() function and the results stored" and Change: "size calls are made to the fputc() function taking the values" to "the function shall behave as if size calls were made to the fputc() function taking the values" Shade and margin code CX (or XSI?) the first 9 words of the new phrase in each case. [Ed recommendation: Accept as marked (really a modified reject). The requirement as stated is an ISO C requirement and should be left as is. Change "calls are made to the" to "calls shall be made to the" to make the requirement more explicit] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 154 prindle@voicenet.com (rdvk# 385) [prindle.xsh-169] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 919 Line: 13951 Section: free() Problem: The function strdup() is not included (as an XSI extension) in the list of functions which allocate free-able storage. Action: Add after posix_memalign(): ", strdup()", shade it, and margin code it XSI. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 155 prindle@voicenet.com Bug in XSHd4 (rdvk# 117) [prindle.xsh-54] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 919 Line: 13951 Section: free() Problem: posix_memalign() is part of the ADV option, not ISO C. But it is not shaded or marked so. Action: Shade "posix_memalign(),", and margin code ADV. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 156 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 240) [DST-105] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 919 Line: 13952 Section: free Problem: The "is deallocated" is best read (according to the best rules of English that I can apply) "is in the future deallocated", which doesn't make any sense in this context. (Memory doesn't have a persistent state of "deallocated", which is the other possible interpretation.) Action: "is" ->?> "had previously been". [Ed recommendation: Accept as marked. "is" -> "has been"] _____________________________________________________________________________ Objection Enhancement Request Number 157 adjg@eng.sun.com Bug in XSHd4 (rdvk# 153) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (note the see also's to these functions need to be update to point to getaddrinfo()) _____________________________________________________________________________ Page: 923 Line: 14113 Section: freeaddrinfo Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove getipnodebyaddr(), getipnodebyname(). _____________________________________________________________________________ comment Enhancement Request Number 158 prindle@voicenet.com Bug in XSHd4 (rdvk# 164) [prindle.xsh-76] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 923 Line: 14113 Section: freeaddrinfo() Problem: See also page 1033 line 17655 section getnameinfo() See also page 1016 line 17166 section gethostbyaddr() gai_strerror() should be in the SEE ALSO list. Action: Add gai_strerror() to the SEE ALSO list on each of the referenced pages. _____________________________________________________________________________ comment Enhancement Request Number 159 prindle@voicenet.com Bug in XSHd4 (rdvk# 118) [prindle.xsh-55] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "file" to "file descriptot" on 14137 Add CH The DESCRIPTION is updated regarding failure to close changing the "file" to "file descriptor". _____________________________________________________________________________ Page: 926 Line: 14136 Section: freopen() Problem: The word "descriptor" here is not compatible with ISO C, and is not particularly correct either - descriptors aren't closed, the file itself is closed. Action: Use the ISO C terminolgy: close any file Rather than: close any file descriptor _____________________________________________________________________________ comment Enhancement Request Number 160 prindle@voicenet.com Bug in XSHd4 (rdvk# 119) [prindle.xsh-56] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement. _____________________________________________________________________________ Page: 926 Line: 14142 Section: freopen() Problem: This sentence is for the most part redundant, but more importantly not correct. Line 14137 permits the close to fail regardless of the success of the (subsequent) open. This sentence is not in ISO C. Action: Delete this sentence (paragraph). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 161 prindle@voicenet.com Bug in XSHd4 (rdvk# 120) [prindle.xsh-57] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 930 Line: 14263-14283 Section: frexp() Problem: Two of the prototypes use "value" as the name of the argument, one uses "num". The text references the argument as if it were always "num". ISO C text and prototypes consistently use "value". Action: Change all occurences of "num" to "value" for consistency with ISO C and self-consistency. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 162 prindle@voicenet.com Bug in XSHd4 (rdvk# 121) [prindle.xsh-58] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being handled by the revision to the error handling being applied globally to all the maths functions. _____________________________________________________________________________ Page: 930 Line: 14274 Section: frexp() Problem: I have a question. ISO C says the function behaves in an unspecified manner if value is not a floating point number. We have changed this, as an XSI extension, to returning NaN if value is NaN, leaving only the exponent unspecified. Is this the only case of value not being a floating point number (i.e. is the somewhat informal requirement of "not a floating point number" from ISO C the same as BEING NaN? For example, would a non-normalized floating point value considered a floating point number? Action: If there are values other than NaN that are not floating point numbers, the the ISO C statement about unspecified behavior needs to go back in for those cases. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 163 Joseph S. Myers BUG in XSHd4 (rdvk# 21) Sat, 19 Aug 2000 12:25:43 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team believes that accepting the proposed change would decrease consensus, and the original intent has been to allow some implementations not to handle this , thus the inconsistency is intended, a portable application should not rely on this behavior, nor should they need it. _____________________________________________________________________________ Page: 932 Line: 14331-14333 Section: fscanf Problem: The fscanf specification says "In format strings containing the "%n$" form of conversion specifications, it is unspecified whether numbered arguments in the argument list can be referenced from the format string more than once". The fprintf specification says (page 898 lines 13154-13155) "In format strings containing the "%n$" form of conversion specifications, numbered arguments in the argument list can be referenced from the format string as many times as required". Because fprintf can write into memory with %n specifications, allowing arguments to be referenced multiple times poses no additional problems with scanf beyond those with printf. Because C99 adds a sequence point after the execution of each conversion specifier, there are in fact no problems with allowing this and scanf should be consistent with printf. Action: On page 932 lines 14332-14333, change "it is unspecified whether numbered arguments in the argument list can be referenced from the format string more than once" to "numbered arguments in the argument list can be referenced from the format string as many times as required". Also at page 975 line 15814-15816 section fwscanf comment Change "it is unspecified whether numbered arguments in the argument list can be referenced from the format wide-character string more than once" to "numbered arguments in the argument list can be referenced from the format wide-character string as many times as required". _____________________________________________________________________________ objection Enhancement Request Number 164 Joseph S. Myers BUG in XSHd4 (rdvk# 20) Sat, 19 Aug 2000 12:25:43 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team believes that accepting the proposed change would decrease consensus as it would break existing applications. _____________________________________________________________________________ Page: 932 Line: 14334-14336 Section: fscanf Problem: The fprintf specification (page 899, lines 13191-13193) says that "When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the (N-1)th, are specified in the format string". There seems to be no corresponding wording for fscanf. This wording is needed so that the implementation knows what types to pass successively to va_arg in order to find the Nth argument: there is no general requirement that different pointers can be interchanged as arguments to variadic functions, only one for pointers to void and to character types. Action: Add at end of line 14336 the same wording as for fprintf, "When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the (N-1)th, are specified in the format string.". Also at page 975 line 15817-15819 section fwscanf objection Add at end of line 15819 the same wording as for fwprintf, "When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the (N-1)th, are specified in the format wide-character string.". _____________________________________________________________________________ objection Enhancement Request Number 165 prindle@voicenet.com Bug in XSHd4 (rdvk# 122) [prindle.xsh-59] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 932 Line: 14337-14340 Section: fscanf() Problem: These requirements would not seem to be in ISO C, and should be shaded as a continuation of the XSI extensions above. In particular, requirements about the POSIX locale would be an XSI extension (or CX). Action: Shade this paragraph and margin code XSI (or CX?) [Ed recommendation: Accept as marked, as above but CX shade] ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 166 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 268) [DWC-664] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 932 Line: 14343 Section: fscanf Problem: (fscanf(): character) The term is defined (XBD6d4, P73, L2181-2186) to be a synonym for "form-feed character". Therefore, the phrase " character" expands to "form-feed character character". Note that other changes are needed here as well! Action: Change "(, , , , or characters);" on P932, L14343 to "(s, s, s, s, or s);". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 167 prindle@voicenet.com Bug in XSHd4 (rdvk# 123) [prindle.xsh-60] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 936 Line: 14513-14516 Section: fscanf() Problem: These are not ISO C requirements. Action: Shade this paragraph and margin code CX (as was done for fprintf().) _____________________________________________________________________________ objection Enhancement Request Number 168 prindle@voicenet.com Bug in XSHd4 (rdvk# 124) [prindle.xsh-61] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 939 Line: 14626-14630 Section: fseek() Problem: These requirements would not seem to be in ISO C, and should be shaded. Action: Shade these paragraphs and margin code CX. _____________________________________________________________________________ objection Enhancement Request Number 169 prindle@voicenet.com Bug in XSHd4 (rdvk# 125) [prindle.xsh-62] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 939 Line: 14644-14646 Section: fseek() Problem: First, this entire 3 lines, and not just the shaded portions, is a ISO C extension imposed by a POSIX-based implementation of fseek() on top of lseek(). It talks of things unknown to ISO C. Second, the requirement is incorrect because a trailing ", and" is missing. Action: Shade the entire paragraph except the words "The fseek()" and "functions shall fail if" and margin code CX. Change "invoked:" to "invoked, and:". [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 170 prindle@voicenet.com Bug in XSHd4 (rdvk# 127) [prindle.xsh-64] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept the change below, add a note to CH that the EPIPE error case is changed to ESPIPE. _____________________________________________________________________________ Page: 940 Line: 14669 Section: fsetpos() Problem: The first EPIPE should be ESPIPE. Action: Replace EPIPE with ESPIPE. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 171 prindle@voicenet.com Bug in XSHd4 (rdvk# 126) [prindle.xsh-63] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 942 Line: 14748-14750 Section: fsetpos() Problem: The set of errors, and the conditions under which the function shall fail (as opposed to may fail) should be the same as for fseek() with the exception of the EOVERFLOW errors. Action: Replace these lines by lines 14644-14673 changed so that fseek() is replaced by fsetpos(), and fseeko() and the EOVERFLOW errors are removed. But see [prindle.xsh-64] first, to fix a typo. _____________________________________________________________________________ comment Enhancement Request Number 172 prindle@voicenet.com Bug in XSHd4 (rdvk# 128) [prindle.xsh-65] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 944 Line: 14789-14791 Section: fstat() Problem: This paragraph is in conflict with the two shaded paragraphs above it. Action: Move this paragraph up to immediately after line 14786, and change "all file types" to "all other file types". [Ed recommendation: Accept] ------------------------------------------------------------------------------- __________________________________________________________________________________ objection Enhancement Request Number 173 IEEE.BALLOTER BUG in P1003.1/D4 (rdvk# 403) [james.bottomley@steeleye.com_969553192.29887_ieee] Wed Sep 27 16:14:11 BST 2000 __________________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The proposed additions are outside the scope of the project. Bringing it in scope would require an interpretation, corrigenda or resolution from an appropriate body. __________________________________________________________________________________ Page: 950 Line: 14955 Section: fsync Problem: There should be some primitive for synchronising a directory as well as a file. A large number of applications write data to a temporary file, commit the data and rename the temporary file over the original and would now like to commit the rename. Although nothing in the draft rules out use of fsync() for this, fsync() should explictly permit the passing of a file descriptor of a directory (which must be read only) and should commit all cached changes associated with that directory. Action: On line 14957 change "...associated with the file described..." to "...associated with the file or directory described..." After line 14963 (in DESCRIPTION) add the following note: "Note: the file descriptor may be open read only if it indicates a directory" On line 14979 change "...modifications to a file to be..." to "...modifications to a file or directory to be..." On line 14995 change "...for at least some files that can..." to "...for at least some files or directories that can..." __________________________________________________________________________________ objection Enhancement Request Number 174 IEEE.BALLOTER BUG in P1003.1/D4 (rdvk# 402) [james.bottomley@steeleye.com_969553357.29917_ieee] Wed Sep 27 16:14:11 BST 2000 __________________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: __________________________________________________________________________________ Page: 950 Line: 14957 Section: fsync Problem: The term "description" is wrong. Action: On lines 14956-14957 change "...for the open file description named by..." to "...for the open file descriptor named by..." [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 175 prindle@voicenet.com Bug in XSHd4 (rdvk# 129) [prindle.xsh-66] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 954 Line: 15107,15113 Section: ftime() Problem: This legacy function fails to suggest clock_gettime() as an alternative. Action: Add to end of line 15107: "Realtime applications should use clock_gettime() to determine the current time instead of ftime()." Add clock_gettime() to list of see-also's on line 15113 _____________________________________________________________________________ editorial Enhancement Request Number 176 gwc@unisoft.com BUG in XSHd4 ftruncate (rdvk# 189) {gwc ftruncate 1} Thu, 21 Sep 2000 16:52:27 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 958 Line: 15216 Section: ftruncate Problem: It should say the signal is sent to the thread, not the process. Action: Change "process" to "thread". [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 177 prindle@voicenet.com Bug in XSHd4 (rdvk# 130) [prindle.xsh-67] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 965 Line: 15419-15421 Section: fwide() Problem: This is not an ISO C requirement. Action: Shade this paragraph and margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 178 prindle@voicenet.com Bug in XSHd4 (rdvk# 131) [prindle.xsh-68] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because, see ERN 130 and ERN 179 _____________________________________________________________________________ Page: 966 Line: 15457-15705 Section: fwprintf() Problem: See also page all line all section all [global search necessary] The description of this function, unlike others that deal with ISO C wide characters (e.g. fgetwc), does not substitute the POSIX terminology "character" for the ISO terminology "wide character". For consistency, it should. Frankly, I don't like either alternative - i.e. in either case, the term "character" appears ambiguous (it isn't, but due to common usage, it appears to be). My preferred solution would have been using the terms "byte" and "wide character", avoiding "character" altogether. But so be it. Action: Change all occurrences (in document) of "wide character" or "wide-character" to "character". Factor in the effect of additional shading that might be necessary depending on the resolution of [prindle.xsh-45]. _____________________________________________________________________________ comment Enhancement Request Number 179 Sandra O'donnell annotation of aardvark for XSH (rdvk# 409) [compaq-smo-005] Thu, 28 Sep 2000 13:57:15 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 966 Line: 15457-15705 Section: fwprintf() [Annotation to [prindle.xsh-68] Problem: I strongly object to Frank Prindle's proposal to replace all instances of "wide character" with "character." It is not true that POSIX uses the term "character" to mean what ISO C calls a "wide character". Here are the definitions: [from ISO/IEC 9899:1999 Programming Languages -- C] 3.7.3 wide character bit representation that fits in an object of type wchar_t, capable of representing any character in the current locale [from XBD, Issue 6, page 56, lines 1791-1796] 3.89 character A sequence of one or more bytes representing a single graphic symbol or control code Note: This term corresponds to the ISO C standard term multi-byte character, where a single-byte character is a special case of a multi-byte character. Unlike the usage in the ISO C standard, character here has no necessary relationship with storage space, and byte is used when storage space is discussed. I am not positive whether Frank actually is referring to XBD when he refers to "POSIX," or to the existing POSIX document (ISO/IEC 9945-1). The version of POSIX I have uses the same definition of "character" as that listed for XBD above, however. Note especially that the ISO C definition of "wide character" uses the plain term "character". It is clear that ISO C considers "wide character" and "character" to be two different things. It's also clear that ISO C's "wide character" refers to data within a wchar_t data type. The XBD definition of "character" has no relationship with wchar_t. Action: Do not change the existing terminology in fwprintf() or throughtout the document from "wide character" to "character." Such a change would be incorrect considering the definitions of these terms. _____________________________________________________________________________ comment Enhancement Request Number 180 Joseph S. Myers BUG in XSHd4 (rdvk# 19) Fri, 18 Aug 2000 21:15:47 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 967 Line: 15517 Section: fwprintf Problem: As with rdvk#1 for fprintf, %'F should be allowed for fwprintf since %'f is. Action: Change "%f" to "%f, %F". _____________________________________________________________________________ Objection Enhancement Request Number 181 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 241) [DST-106] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 969 Line: 15626 Section: fwprintf Problem: The string "p1d" makes no sense to me in this context. It almost looks like vi editing commands. I think what's intended is something like what's at 15607. (Note the different font; I'd prefer CW for both, but at least be consistent.) Yes, I realize that p is supposed to be the exponent marker character, but is the space intended, and what happened to the sign of the exponent? I presume that this is properly expressed at lines 235 and 236 of the document from which it was cut and pasted. (See lines 15628 and 15632 for where those line numbers came from.) Action: As above, and remove "235)" and "236)" (unless you really intend that there are only 236 distinct values for "double" :-)). I belive there are other instances of this identical text in the other members of the printf family. Please find and fix all (look for "p1d"). I found: 13303, 15626 [Ed recommendation: Accept as marked this should be p+/-d ] _____________________________________________________________________________ objection Enhancement Request Number 182 prindle@voicenet.com Bug in XSHd4 (rdvk# 133) [prindle.xsh-70] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 975 Line: 15797 Section: fwscanf() Problem: Like scanf(), wscanf() should have its format string qualified restrict because the variable arg list might have another pointer and the function won't work properly if they specify overlapping storage. Action: Change "*format" to "*restrict format". ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 183 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 269) [DWC-665] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 975 Line: 15825-15826 Section: fwscanf Problem: (fwscanf(): character) The term is defined (XBD6d4, P73, L2181-2186) to be a synonym for "form-feed character". Therefore, the phrase " character" expands to "form-feed character character". Note that other changes are needed here as well! Action: Change "(, , , , or characters);" on P975, L15825-15826 to "(s, s, s, s, or s);". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 184 prindle@voicenet.com Bug in XSHd4 (rdvk# 132) Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 979 Line: 16001-16002,16006-16007 Section: fwscanf() [prindle.xsh-69] Problem: Shading snafu here. Action: Fix shading to encompass full text of extensions. [Ed recommendation: Accept as marked, should be "and set errno" on 16001, and all the line on 16006] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 185 prindle@voicenet.com Bug in XSHd4 (rdvk# 134) [prindle.xsh-71] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change line 16048 from "an error that is listed" to "an error value for the getaddrinfo() and getnameinfo() functions listed in the header". Change line 16050 to: When the ecode argument is one of the following values listed in the header EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY, EAI_NONAME EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM the function returns.... error. _____________________________________________________________________________ Page: 981 Line: 16048-16052 Section: gai_strerror() Problem: The text here is not terribly explicit about which values listed in . I'm assuming only error values are valid, and I'm also assuming that both the set of errors {HOST_NOT_FOUND, NO_DATA, NO_RECOVERY, TRY_AGAIN} as well as the set of errors {EAI_*} are handled correctly by this function, in spite of its name. Action: To avoid all confusion, because defines lots of kinds of values, enumerate here exactly the set of valid values (from ) for ecode. _____________________________________________________________________________ objection Enhancement Request Number 186 prindle@voicenet.com Bug in XSHd4 (rdvk# 162) [prindle.xsh-74] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 999 Line: 16598-16610 Section: getenv() Problem: There are a number of extensions here beyond the ISO C standard that are not marked as such. See action below. Action: On line 16598-16599, shade "setenv(), unsetenv()," and margin code CX. On line 16599-16600, shade "in this volume...200x" and margin code CX. Shade all of lines 16601-16602 and margin code CX. On line 16610, shade "setenv(), unsetenv()," and include in margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 187 adjg@eng.sun.com Bug in XSHd4 (rdvk# 157) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1021 Line: All Section: getipnodebyaddr Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove this page. _____________________________________________________________________________ objection Enhancement Request Number 188 ajosey@opengroup.org Bug in XSHd4 getgrgid_r (rdvk# 33) {tog.aug30.pasc.1.116} Tue, 29 Aug 2000 16:59:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1005 Line: 16777 Section: getgrgid_r Problem: IEEE PASC Interpretation #116 has raised an issue for which the sponsor has recommended the following action. Action: Change "characters" to "bytes" on line 16777 Add to CH IEEE PASC Interpretation 1003.1-96 #116 has been applied changing the description of the size of the buffer from bufsize characters to bytes. [Ed recommendation: Accept] _____________________________________________________________________________ Objection Enhancement Request Number 189 adjg@eng.sun.com Bug in XSHd4 (rdvk# 158) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1022 Line: all Section: getipnodebyname Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove this page. _____________________________________________________________________________ Comment Enhancement Request Number 190 Andries.Brouwer@cwi.nl BUG in XSHd4 (rdvk# 186) [] Tue, 19 Sep 2000 14:33:05 +0200 (MET DST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1011 Line: 16976 Section: getgroups Problem: getgroups returns the number of supplementary group IDs and possibly also the effective group ID. Thus, the value returned can be at most NGROUPS_MAX+1 as also stated in line 16957. However, line 16976 shows a malloc for one item less. Action: Change line 16975 into ngroups_max = sysconf(_SC_NGROUPS_MAX) + 1; _____________________________________________________________________________ objection Enhancement Request Number 191 IEEE.BALLOTER BUG in P1003.1/D4 (rdvk# 404) [c.harding@opengroup.org_969467195.19020_ieee] Wed Sep 27 16:14:11 BST 2000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The alternative noted below is being done in other ERNs _____________________________________________________________________________ Page: 1013 Line: 17021-17171 Section: unk Problem: There is overlap in functionality between getipnodebyname()/getipnodebyaddr() and getnameinfo()/getaddreinfo(). And there are some circumstances in which getipnodebyname() and getipnodebyaddr() can not be used. Action: The draft should detail the circumstances in which these functions should and should not be used in their respective Application Usage sections, and should cross-refer to each other in their respective "See Also" sections. An acceptable alternative would be to remove getipnodebyname() and getipnodebyaddr(). _____________________________________________________________________________ comment Enhancement Request Number 192 prindle@voicenet.com Bug in XSHd4 (rdvk# 163) [prindle.xsh-75] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see 193,but remember the see-also actions from earlier. Lines 17159-17160 must be updated. _____________________________________________________________________________ Page: 1013 Line: 17022 Section: gethostbyaddr() Problem: I understand that another aardvark is going to remove the getipnode*() functions from this page, as well as the freehostent() function that went with them. If that is done, and no other substitute is provided, the gethostbyaddr() and gethostbyname() need to come out of LEGACY status and join their non-reentrant getservbyname(), getprotobyname(), etc... brethren. (or maybe the anticipated change will make them all reentrant()?) Action: Do whatever the other aardvark says to remove the getipnode*() functionality from this page (and freehostent() from the page it's on) and remove the LEGACY annotations from the remaining functions. This includes removing the LEGACY notation and various text denoting legacy from the h_errno page in XSH, and removing getipnode*() from the list of functions that utilize the error codes defined by in XBD. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 193 adjg@eng.sun.com Bug in XSHd4 (rdvk# 154) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1013 Line: 17022,17029-32,17047-5,17060 Section: gethostbyname Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove mention of getip*(), and delete 17029-32,17047-5. _____________________________________________________________________________ comment Enhancement Request Number 194 prindle@voicenet.com Bug in XSHd4 (rdvk# 63) [prindle.xsh-28] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The proposed change is out of scope, Bringing it in scope would require an interpretation, corrigenda or resolution from an appropriate body. _____________________________________________________________________________ Page: 1013 Line: 17029-17032 Section: gethostbyaddr() Problem: Just a curious note for which I see no rationale: why are thread-safe versions of gethostbyname() et al. provided, but no equivalent thread-safe versions of getnetbyname() et al., getprotobyname() et al., and getservbyname() et al.? Action: For consistency, add functions getipnetbyname(), getipnetbyaddr(), freenetent(), getipprotobyname(), getipprotobynumber(), freeprotoent(), getipservbyname(), getipservbyport(), and freeservent(); using getipnodebyname(), getipnodebyaddr(), and freehostent() as a model. _____________________________________________________________________________ Objection Enhancement Request Number 195 adjg@eng.sun.com Bug in XSHd4 (rdvk# 155) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1014 Line: 17066,17069,17095,17097-17129,17134-6,17138-9 Section: gethostbyaddr Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove isolated mentioned of getip*() and 17134-6,17138-9. _____________________________________________________________________________ Objection Enhancement Request Number 196 adjg@eng.sun.com Bug in XSHd4 (rdvk# 156) [] Thu, 14 Sep 2000 17:20:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove 17153-5. Delete the sentence"Applications shall not call freehostent() for this area." in 17157-8. _____________________________________________________________________________ Page: 1016 Line: 17153-5,17157-8,17159-60,17170-1 Section: gethostbyaddr Problem: The getip*() family of functions has been judged useless since they cannot provide values for the scope id of IPv6. Action: Remove 17153-5. Delete the sentence"Applications shall not call freehostent() for this area." in 17157-8. Remove 17159-60,17170-1 _____________________________________________________________________________ Editorial Enhancement Request Number 197 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 265) [DWC-661] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1040 Line: 17861 Section: getopt Problem: (getopt(): character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " characters" on P1040, L17861 to " characters". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 198 prindle@voicenet.com Bug in XSHd4 (rdvk# 165) [prindle.xsh-77] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1044 Line: 17987-17988 Section: getpgrp() Problem: Incorrect historical assertion in rationale. Action: Change "has been omitted from this...200x" to "is provided by the XSI extension getpgid()" Note that getpgid() is already in the SEE ALSO list, so need not be added there. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 199 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 252) [DST-168] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because this is the only place this is discussed. _____________________________________________________________________________ Page: 1048 Line: 18113 Section: getpriority Problem: This general discussion doesn't belong here, but rather in XBD (where it can be referred to more generally). Action: Delete paragraph, replace with new paragraph at XBD P125 L3481 The scheduling of ordinary processes (as opposed to realtime processes) is affected by the Nice Value. _____________________________________________________________________________ objection Enhancement Request Number 200 ajosey@opengroup.org Bug in XSHd4 getpwnam_r (rdvk# 32) {tog.aug30.pasc.1.116-2} Tue, 29 Aug 2000 16:59:06 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1055 Line: 18228 Section: getpwnam_r Problem: IEEE PASC Interpretation #116 has raised an issue for which the sponsor has recommended the following action. Action: Change "characters" to "bytes" on line 18228 Delete the note to reviewers at 18229 Add to CH IEEE PASC Interpretation 1003.1-96 #116 has been applied changing the description of the size of the buffer from bufsize characters to bytes. [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 201 prindle@voicenet.com Bug in XSHd4 (rdvk# 166) [prindle.xsh-78] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_200 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1055 Line: 18229-18232 Section: getwpnam() Problem: I agree with the proposed change in this Note to Reviewers. Given the terminology change from ISO C to POSIX, it is meaningless to specify a buffer size in terms of (POSIX defined) characters, which are ISO wide characters. Action: Change "characters" to "bytes". _____________________________________________________________________________ comment Enhancement Request Number 202 prindle@voicenet.com Bug in XSHd4 (rdvk# 167) [prindle.xsh-79] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The rules we are following for restrict are from Austin/45r1 and they are as follows : - only functions with two or more parameters need restrict - additionally at least two of the objects pointed to must have the same type. I.e., int foo (int *, double *) does not need a restrict - an exception to the above rule comes with pointers to structures. Since the standard does not define the structures in all details we must assume the worst case which is that it contains an element of the type described by one of the other parameters. I.e., int bar (int restrict *, struct baz restrict *) needs restrict since the structure baz can potentially contain an element of type `int'. Looking at each request here: > See also page 1005 line 16767-16768 section getgrgid() > See also page 1008 line 16864-16865 section getgrnam() No. Different types. > See also page 921 line 13988-13989 section freeaddrinfo() *FIX IN HEADER ONLY* getaddrinfo() in XBD on page 312 should follow the prototype in XSH. > See also page 1013 line 17031-17032 section gethostbyaddr() No. Different types. > See also page 1032 line 17587-17589 section getnameinfo() *FIX IN HEADER ONLY* getnameinfo() in XBD on page 312 should follow the prototype in XSH. > See also page 1055 line 18216-18217 section getpwnam() > See also page 1058 line 18323-18324 section getpwuid() No. Different types. > See also page 1481 line 30966-30968 section pselect() > See also page 1481 line 30969-30971 section pselect() *FIX IN HEADER ONLY* Yes. pselect() must be like select(). In XBD and XSH. > See also page 1042 line 17897 section getpeername() *last argument* > See also page 1072 line 18688 section getsockname() *last argument* Yes. Missing restrict. > See also page 700 line 6849 section clock_nanosleep() I think this is a case where restrict is actually wrong. I at least use nanosleep() in a way which puts the remaining time in the same variable. > See also page 740 line 8127 section ctime() > See also page 1429 line 29577-29582 section posix_trace_attr_getclockres() No. Different types. > See also page 1431 line 29640-29651 section posix_trace_attr_getinherited() Restrict for all pointer argument of posix_trace_attr_getinherited(), posix_trace_attr_getlogfullpolicy(), and posix_trace_attr_getstreamfullpolicy(). The same changes for XBD. Not for posix_trace_attr_setinherited(), posix_trace_attr_setlogfullpolicy(), and posix_trace_attr_setstreamfullpolicy() since those have only one pointer argument. > See also page 1434 line 29752-29767 section posix_trace_attr_getlogsize() restrict for all pointer arguments of posix_trace_attr_getlogsize(), posix_trace_attr_getmaxdatasize(), posix_trace_attr_getmaxsystemeventsize(), posix_trace_attr_getmaxusereventsize(), and posix_trace_attr_getstreamsize(). The same changes for XBD. Not for posix_trace_attr_setlogsize(), posix_trace_attr_setmaxdatasize(), posix_trace_attr_setstreamsize(). > See also page 1442 line 29962-29965 section posix_trace_create() Restrict for both functions. Also in XBD. > See also page 1446 line 30128-30129 section posix_tace_event() Restrict for both functions. Also in XBD. > See also page 1448 line 30206-30207 section posix_trace_eventid_equal() Restrict for posix_trace_trid_eventid_open(). Also in XBD. > See also page 1450 line 30293-30294 section posix_trace_eventset_add() Restrict for posix_trace_eventset_ismember(). Also in XBD. > See also page 1452 line 30350-30351 section > posix_trace_eventtypelist_getnext_id() Restrict for posix_trace_eventtypelist_getnext_id(). Also in XBD. > See also page 1460 line 30522-30531 section posix_trace_getnext_event() Restrict for all three functions. Also in XBD. _____________________________________________________________________________ Page: 1076 Line: 18850 Section: getsubopt() Problem: See also page 1005 line 16767-16768 section getgrgid() See also page 1008 line 16864-16865 section getgrnam() See also page 921 line 13988-13989 section freeaddrinfo() *FIX IN HEADER ONLY* See also page 1013 line 17031-17032 section gethostbyaddr() See also page 1032 line 17587-17589 section getnameinfo() *FIX IN HEADER ONLY* See also page 1055 line 18216-18217 section getpwnam() See also page 1058 line 18323-18324 section getpwuid() See also page 1481 line 30966-30968 section pselect() See also page 1481 line 30969-30971 section pselect() *FIX IN HEADER ONLY* See also page 1042 line 17897 section getpeername() *last argument* See also page 1072 line 18688 section getsockname() *last argument* See also page 700 line 6849 section clock_nanosleep() See also page 740 line 8127 section ctime() See also page 1429 line 29577-29582 section posix_trace_attr_getclockres() See also page 1431 line 29640-29651 section posix_trace_attr_getinherited() See also page 1434 line 29752-29767 section posix_trace_attr_getlogsize() See also page 1442 line 29962-29965 section posix_trace_create() See also page 1446 line 30128-30129 section posix_tace_event() See also page 1448 line 30206-30207 section posix_trace_eventid_equal() See also page 1450 line 30293-30294 section posix_trace_eventset_add() See also page 1452 line 30350-30351 section posix_trace_eventtypelist_getnext_id() See also page 1460 line 30522-30531 section posix_trace_getnext_event() As I understand it, if a function: a) has more than one argument that is a pointer b) stores some data by derereferencing at least one pointer argument c) is not guaranteed to work if an output buffer (as in b) overlaps any other buffer referenced by a pointer argument Then all the pointer arguments to that should have the restrict qualifier in its prototype. If this is true, then a number of functions need restrict qualifiers added to their prototypes, both on their man page and on the associated header page in XBD. Action: Add the restrict qualifier to each of the pointer arguments passed on the lines noted above. Fix the header page too (in some cases above, only the header page need be fixed). Fix the prototype also if/where it appears on a pointer page pointing back to the pages noted above. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 203 prindle@voicenet.com Bug in XSHd4 (rdvk# 101) [prindle.xsh-38] Thu, 14 Sep 2000 07:49:18 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Yes, do the changes (note that ERN 202 already covered getsockname/getpeername) _____________________________________________________________________________ Page: 1079 Line: 18986 Section: gettimeofday() Problem: See also page 1072 line 18687-18688 section getsockname() See also page 1042 line 17896-17897 section getpeername() It is my understanding from C99 that use of the restrict qualifier in an argument list is only meaningful if more than one function argument is a pointer (or could be a pointer, in the case of variable args), and then only effective if all pointer args are so qualified. C99 is quite consistent in this usage. D4 is inconsistent in these 3 functions. Action: Change "socklen_t *address_len" to "socklen_t *restrict address_len" (p 1042) Change "socklen_t *address_len" to "socklen_t *restrict address_len" (p 1072) Change "void *tzp" to "void *restrict tzp" (p 1079) ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 204 drepper@redhat.com Bug in XSHd4 gettimeofday() (rdvk# 25) {ud-3} Mon, 21 Aug 2000 05:47:49 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1079 Line: 18986 Section: gettimeofday() Problem: In my restrict proposal I incorrectly left the parameters of gettimeofday unmarked. The editors partly corrected this mistake of mine but missed to add restrict to the second parameter. Action: Replace line 18986 with: int gettimeofday(struct timeval *restrict tp, void *restrict tzp); [Ed recommendation: Accept as marked, as action above and also add CH: The restrict keyword is added to the prototype for gettimeofday() for alignment with the ISO/IEC 9899:1999 standard. ] _____________________________________________________________________________ objection Enhancement Request Number 205 drepper@redhat.com Bug in XSHd4 glob() (rdvk# 26) {ud-2} Mon, 21 Aug 2000 05:47:49 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1086 Line: 19175-19177 Section: glob() Problem: The prototype for glob was adjusted for d4 following an document of mine. But: - I want to correct one problem I introduced and - the editor was a bit too eager with adding restricts. The first function parameter of the parameter errfunc must not have an restrict. There is no second pointer parameter. This restrict wasn't present in my proposal. Additionally, I'd like to remove the restrict from the errfunc parameter itself. Since this is a function parameter the compiler will not assume possible aliasing with any of the other parameters. Action: Replace lines 13175-13177 with int glob(const char *restrict patternm int flags, int(*errfunc)(const char *epath, int eerrno), glob_t *restrict pglob); [Ed recommendation: Accept ] _____________________________________________________________________________ comment Enhancement Request Number 206 prindle@voicenet.com Bug in XSHd4 (rdvk# 170) [prindle.xsh-82] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: as action below, but not GLOB_NOSYS _____________________________________________________________________________ Page: 1088 Line: 19265 Section: glob() Problem: On the freeaddrinfo() page, you've set a precedent (and elsewhere, I've seen it but just can't remember) of enumerating the [non-errno] error codes returned in the ERRORS section, and showing their meanings. You should do the same her, as to say "no errors are defined" is misleading. Furthermore, unless you do this, the set of values that may be returned is not well defined, as there are other non-zero constants defined in that are not error codes. Action: Replace this line with: The glob() function shall fail and return the corresponding value if: [GLOB_ABORTED] The scan was stopped because GLOB_ERR was set or (*errfunc)() returned non-zero. [GLOB_NOMATCH] The pattern does not match any existing path name, and GLOB_NOCHECK was not set in flags. [GLOB_NOSPACE] An attempt to allocate memory failed. [GLOB_NOSYS] The implementation does not support this function. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 207 prindle@voicenet.com Bug in XSHd4 (rdvk# 171) [prindle.xsh-83] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1090 Line: 19339 Section: gmtime() Problem: Shading does not extend to end of this line, and line extends beyond page margin. Action: Fix it. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 208 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 253) [DST-169] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The Base working group agrees with the problem statement and has adopted by resolution BWG/009-10-2000 the following new interface: SYNOPSIS XSI #include int posix_openpt ( int oflag); DESCRIPTION The posix_openpt() function shall establish a connection between a master device for a pseudo-terminal and a file descriptor. The file descriptor is used by other I/O functions that refer to that pseudo-terminal. The file status flags and file access modes of the open file description shall be set according to the value of oflag . Values for oflag are constructed by a bitwise-inclusive OR of flags from the following list, defined in : O_RDWR Open for reading and writing. O_NOCTTY If set posix_posix_openpt() shall not cause the terminal device to become the controlling terminal for the process. The behavior of other values for the oflag argument is unspecified. RETURN VALUE Upon successful completion, the function shall open a master pseudo-terminal device and return a non-negative integer representing the lowest numbered unused file descriptor. Otherwise, -1 shall be returned and errno set to indicate the error. ERRORS The posix_openpt() function shall fail if: [EMFILE] {OPEN_MAX} file descriptors are currently open in the calling process. [ENFILE] The maximum allowable number of files is currently open in the system. The posix_openpt() function may fail if: [EINVAL] The value of the oflag argument is not valid. [EAGAIN] Out of pseudo-terminal resources [XSR] [ENOSR] Out of STREAMS resources EXAMPLE Opening a pseudo-terminal and returning the name of the slave device and a file descriptor #include #include int masterfd, slavefd; char *slavedevice; masterfd = posix_openpt (O_RDWR|O_NOCTTY); if (masterfd == -1 || grantpt (masterfd) == -1 || unlockpt (masterfd) == -1 || (slavedevice = ptsname (masterfd)) == NULL) return -1; printf ("slave device is: %s\n", slavedevice); slavefd = open (slave, O_RDWR|O_NOCTTY); if (slavefd < 0) return -1; .... APPLICATION USAGE This function is a method for portably obtaining a file descriptor of a master terminal device for a pseudo-terminal. The grantpt() and the ptsname() functions can be used to manipulate mode and ownership permissions, and to obtain the name of the slave device respectively. RATIONALE The standard developers considered the matter of adding a special device for cloning master pseudo-terminals, the /dev/ptmx device, however concensus could not be reached, and it was felt that adding a new function would permit other implementations. The posix_openpt() function is designed to complement the grantpt() ptsname() and unlockpt() functions. On implementations supporting the /dev/ptmx clone device, opening the master device of a pseudo-terminal is simply mfdp = open("/dev/ptmx", oflag ); if (mfdp < 0) return -1; SEE ALSO grantpt, open, ptsname, unlockpt _____________________________________________________________________________ Page: 1092 Line: 19400 Section: grantpt Problem: Nowhere that I can find in the standard does it say how a file descriptor to a pseudo-tty can be obtained. Thus it cannot be done portably, and this interface (and it's brethren) are useless and should be deleted. Or the other shoe should be dropped and a function to get a fd on a pty (or a pty name) should be included. (I think this is more productive.) Although it would be possible to say something about entries in /dev, I don't believe that that's particularly useful, given what a pain that interface is. I am aware of existing practice in this regard, but I do not know what System V uses. Again, if it cannot be demonstrated how a portable application can use the function, it does not belong in the standard. Action: Delete. Or will the 4.3bsd openpty() function serve? There may be other existing practice I'm not aware of. [Ed recommendation: NONE open() is the function to get a fd on a pty] _____________________________________________________________________________ editorial Enhancement Request Number 209 ajosey@opengroup.org Bug in XSHd4 hcreate (rdvk# 31) {tog.aug24.1} Thu, 24 Aug 2000 15:24:47 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1094 Line: 19565 Section: hcreate Problem: The following text has been added in Issue 6, but no change history: 19484 These functions need not be reentrant. A function that is not required to be reentrant is not 19485 required to be thread-safe. Action: Add to CH, A note is added to the DESCRIPTION that these functions are not required to be reentrant. [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 210 prindle@voicenet.com Bug in XSHd4 (rdvk# 172) [prindle.xsh-84] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1098 Line: 19600-19606 Section: htons() Problem: See also inet_lnaof(), inet_makeaddr(), inet_netof(), inet_network(), inet_ntoa(), pthread_barrier_init(). Not clear that this page should be here. I thought the rule was if a function's name immediately alphabetically follows the previous function and it is described on the previous function's page, a pointer page was not necessary. Action: Delete these pointer pages. [unless the rules have changed] Actually, the more I look, the more this rule seems applied arbitrarily. E.g.: pthread_barrier_init() is a pointer page immediately following its main page, but pthread_barrierattr_init() is not given a pointer page (i.e. according to the rule above). The posix_trace_*() functions are also treated inconsistently. We need to pick one rule [I don't care what] and use it everywhere. [Ed recommendation: Accept as marked Originally we removed ptrs where they were in alphabetical order, but all new ones have additional ptrs. We will add more ptr pages, build book, and then remove superfluous ones at the final proof stage] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 211 prindle@voicenet.com Bug in XSHd4 (rdvk# 173) [prindle.xsh-85] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being handled by the revision to the error handling being applied globally to all the maths functions. _____________________________________________________________________________ Page: 1099 Line: 19610-19631 Section: hypot() Problem: These functions are incorrectly shaded and identified as XSI functionality. There are omissions from ISO C and extensions to ISO C. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Before the period on line 19616, add: without undue overflow or underflow. A range error may occur. Shade and mark with margin code CX all of lines 19622-19626 and line 19629. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 212 ajosey@opengroup.org Bug in XSHd4 hypot (rdvk# 7) {tog.aug14.3} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 1099 Line: 19610 Section: hypot Problem: The hypot() function is in the C Standard and should not be XSI shaded. Action: Remove the XSI shading from the complete synopsis block. Add to CH, The hypot() function is no longer XSI shaded. _____________________________________________________________________________ objection Enhancement Request Number 213 ajosey@opengroup.org Bug in XSHd4 (rdvk# 80) {tog.sep4.11} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 1099 Line: 19624 Section: hypot Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 19624 and 19629 _____________________________________________________________________________ editorial Enhancement Request Number 214 prindle@voicenet.com Bug in XSHd4 (rdvk# 174) [prindle.xsh-86] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1106 Line: 19818 Section: if_freenameindex() Problem: "ifnameindex()" on this line misspelled - should be "if_nameindex()". Action: Fix it. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 215 Sandra O'donnell Bug in XSH (rdvk# 408) [compaq-smo-006] Thu, 28 Sep 2000 15:43:02 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use "ISO-8859-1" in the action text _____________________________________________________________________________ Page: 1087 Line: 40430-40433 Section: setlocale() Problem: The current example of a locale name is out-of-date and partially inaccurate. The text reads: setlocale(LC_ALL, "Fr_FR.8859"); In this example, all categories of the international environment are set to the locale corresponding to the string "Fr_FR.8859", or to the French language as spoken in France using the ISO/IEC 8859-1:1998 standard codeset. Common practice is to follow ISO 639 for language codes, and they use two lowercase letters (i.e., "fr" rather than "Fr"). Also, although there is no agreement on ways to specify codesets, I am not aware of *any* implementation that uses only "8859" to refer to ISO/IEC 8859-1. Because that standard contains so many commonly-used parts, a locale name would always include the part number in some way. It might be "8859-1" or "88591" or "ISO8859-1" or something similar, but never just "8859". Action: Change the text as follows: setlocale(LC_ALL, "fr_FR.ISO8859-1"); In this example, all categories of the international environment are set to the locale corresponding to the string "fr_FR.ISO8859-1", or to the French language as spoken in France using the ISO/IEC 8859-1:1998 standard codeset. _____________________________________________________________________________ objection Enhancement Request Number 216 prindle@voicenet.com Bug in XSHd4 (rdvk# 175) [prindle.xsh-87] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1110 Line: 19933 Section: ilogb() Problem: These functions are from ISO C. The standard ISO C disclaimer is missing. Action: Add after this line: 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. _____________________________________________________________________________ editorial Enhancement Request Number 217 ajosey@opengroup.org Bug in XSHd4 ilogb (rdvk# 3) {tog.aug14.4} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1110 Line: 19962 Section: ilogb Problem: Missing change history Action: Add to CH The ilogb() function is no longer XSI shaded. [Ed recommendation: Accept as marked, as above, but add the ISO C disclaimer block] _____________________________________________________________________________ comment Enhancement Request Number 218 prindle@voicenet.com Bug in XSHd4 (rdvk# 176) [prindle.xsh-88] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1114 Line: 20074 Section: inet_addr() Problem: The standard text not requiring inet_ntoa() to be thread-safe is missing. This function is properly included in the front-matter table. Action: Add after this line: The inet_ntoa() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 219 Sandra O'donnell red-msg-02.redmond.corp.microsoft.com> (rdvk# 405) [compaq-smo-004] Wed, 27 Sep 2000 13:43:17 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: minor editorial change on p 1145 to separate out a para. Note that The para on lines 20935-20937 constrains these functions suitably and no further changes are required. _____________________________________________________________________________ Page: 1140 Line: 20893 Section: isalnum() Problem: [Annotation to [prindle.xsh-89] and [Copeland-xsh-3]] Frank Prindle and Jeff Copeland raise issues about the descriptions of the is*() and isw*() functions. My comment has only to do with the is*() functions. Quoting the relevant parts of Jeff's annotation: Let's remember that is*() really does check an int, not a char (nor a wint_t cast up from a wchar_t) so the underlying tables can be anything. However, there's probably a portability issue here on relying on some particular encoding of a multi-byte character in the argument to an is*() function. That is, given the multi-byte character 0x84 0x40 (cyrillic A at double display width in SJIS), how do I pass that argument to isalpha()? Or do I? . . . Note that the C definition of byte, character and multi-byte character are: ...[byte definitions deleted because they aren't ... relevant to my followup] ... 3.5 [#1] character bit representation that fits in a byte 3.14 [#1] multibyte character sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment [#2] NOTE The extended character set is a superset of the basic character set. Note in particular 3.5!! . . . We need a clarification -- remembering that there are single-byte characters, multi-byte characters, and wide characters -- to the effect that the portable space of is*() is the single-byte characters. This probably also means being very careful in the is*() and isw*() functions [and elsewhere!] to not use the abstraction "character" but to explicitly refer to "wide character", "single-byte character", or "multi-byte character". Action: First, I think no clarification is needed regarding the is*() functions. See, for example, page 1141, lines 20935-20936 of iswalpha(): "In all cases c is an int, the value of which the application shall ensure is representable as an unsigned char or equal to the value of the macro EOF." Since the value must be representable *as AN unsigned char* (emphasis added), that means only single-byte characters will produce predictable results. The text goes on to note that if c is something other than what can be represented in an unsigned char, the behavior is undefined. I see no need to add any further clarification to the is*() functions. This also means, in answer to Jeff's question: "...given the multi-byte character 0x84 0x40 (cyrillic A at double display width in SJIS), how do I pass that argument to isalpha()? Or do I?" you don't pass this argument to isalpha(). Or if you do, you know that the results are undefined. On the more general issue of the definition of "character", Jeff quotes a single definition from the C standard, but I'm looking at ISO/IEC 9899:1999 (Programming languages -- C), and the definitions (note plural) of "character" are: 3.7 character member of a set of elements used for the organization, control, or representation of data 3.7.1 character single-byte character bit representation that fits in a byte Further, the definition of "character" in Base Definitions, section 3.89 Character (lines 1792-1796) is: "A sequence of one or more bytes representing a single graphic symbol or control code. Note: This term corresponds to the ISO C standard term multi-byte character, where a single-byte character is a special case of a multi-byte character. Unlike the usage in the ISO C standard, character here has no necessary relationship with storage space, and byte is used when storage space is discussed." The term "character" causes no end of confusion because it is used in two very different ways -- as an abstract thing (think of an "A" regardless of its encoding) -- and as a data type that contains abstract characters. If I could wave a magic wand and start over with definitions, I'd use "character" *only* to refer to the abstract thing. It would have nothing to do with bytes, bits, storage size, data types, multi-anything, and so on. Instead, I'd use specific terms like wchar_t, char, byte, etc. to refer to the ways in which an abstract character is manipulated in software. Unfortunately, I'm all out of magic wands, and we have to deal with the layers of crud that have built up over the years. That often means using "character" in two different ways throughout the document, and hoping that we provide enough context so that a reader understands whether we're referring to the abstract thing or the historical single-byte character. Since ISO C provides both definitions, I think it is misleading to look at the single one Jeff listed. The abstract definition exists, and the need to refer to the abstract thing exists, too. We should, of course, be careful to spell out limitations. If a given function really only operates on wide characters or only on single-byte characters, the text should say that clearly. I think the existing text for is*() functions does spell out the limitation. _____________________________________________________________________________ comment Enhancement Request Number 220 prindle@voicenet.com Bug in XSHd4 (rdvk# 177) [prindle.xsh-89] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_219 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1140 Line: 20893-20900 Section: isalnum() Problem: See also all the is*() and to*() functions and the isw*() functions and tow*() functions. Wow, it seems we've dug ourselves into a nasty hole here. Other functions which deal with single-byte vs. multi-byte characters have been using the POSIX terminology "byte" for single-byte, and "character" for multi-byte, in spite of ISO C using the terminology "character" for single-byte and "wide character" or "wide-character" for multibyte (noun vs. adjective forms). Here we again have the same parallel structure (e.g. isalnum() vs. iswalnum()) but use the ISO C terminology "character" and "wide-character". In this case, substituting byte for character seems awkward - i.e. talking about a byte of class alpha is contrary to the XBD matter that discusses locale, which uses the term character in a generic sense. Action: What to do? I was going to suggest changing all the non-w functions to use the word byte consistently. Somehow, it seems a poor solution. Call this unresponsive if you will, but I defer to a higher authority on this one and just want to point it out. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 221 jeffcope@microsoft.com (rdvk# 406) [Copeland-xsh-3] Tue, 26 Sep 2000 11:34:36 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_219 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1140 Line: 20893 Section: isalnum() Problem: [Annotation to [prindle.xsh-89]] Frank Prindle raises an issue about the descriptions of the is*() and isw*() functions Let's remember that is*() really does check an int, not a char (nor a wint_t cast up from a wchar_t) so the underlying tables can be anything. However, there's probably a portability issue here on relying on some particular encoding of a multi-byte character in the argument to an is*() function. That is, given the multi-byte character 0x84 0x40 (cyrillic A at double display width in SJIS), how do I pass that argument to isalpha()? Or do I? Worse, what happens if my multi-byte encoding is such that MB_CUR_MAX > sizeof(int)? (I don't think that putting a restriction on the implementation that forces MB_LEN_MAX <= sizeof(int) [remember stateful encodings can have a shift sequence + multi-byte chars] is the right answer!) Note that the C definition of byte, character and multi-byte character are: 3.4 [#1] byte addressable unit of data storage large enough to hold any member of the basic character set of the execution environment [#2] NOTE 1 It is possible to express the address of each individual byte of an object uniquely. [#3] NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. 3.5 [#1] character bit representation that fits in a byte 3.14 [#1] multibyte character sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment [#2] NOTE The extended character set is a superset of the basic character set. Note in particular 3.5!! Action: We need a clarification -- remembering that there are single-byte characters, multi-byte characters, and wide characters -- to the effect that the portable space of is*() is the single-byte characters. This probably also means being very careful in the is*() and isw*() functions [and elsewhere!] to not use the abstraction "character" but to explicitly refer to "wide character", "single-byte character", or "multi-byte character". _____________________________________________________________________________ Editorial Enhancement Request Number 222 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 266) [DWC-662] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1145 Line: 21073 Section: isblank Problem: (isblank(): character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " character;" on P1145, L21073 to ";". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 223 prindle@voicenet.com Bug in XSHd4 (rdvk# 178) [prindle.xsh-90] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Based on the poll of the user base, and the duplication between this function and other facilities in the standard, the isfdtype() function will be removed. _____________________________________________________________________________ Page: 1148 Line: 21171 Section: isfdtype() Problem: In , S_IFSOCK (and the other XSI extension S_IF* types) is defined to be the symbolic name of a value with type mode_t. Therefore, argument fdtype should be of type mode_t, not int. Action: Replace the second int in prototype with mode_t, and fix prototype in XBD also. _____________________________________________________________________________ editorial Enhancement Request Number 224 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 351) {aj.tog.26sep.20} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1193 Line: 22480 Section: kill Problem: wording Action: Change "matchs" to "matches" _____________________________________________________________________________ objection Enhancement Request Number 225 prindle@voicenet.com Bug in XSHd4 (rdvk# 179) [prindle.xsh-91] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1198 Line: 22646,22649 Section: labs() Problem: The wording here speaks only of the long integer operand - do not mention the long long integer operand. Action: Change 22646 first sentence to: The labs() function shall compute the absolute value of the long integer operand i. The llabs() function shall compute the absolute value of the long long integer operand i. Change 22649 to: The labs() function shall return the absolute value of the long integer operand. The llabs() function shall return the absolute value of the long long integer operand. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 226 prindle@voicenet.com (rdvk# 199) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1204 Line: 22796-22807,22810-22813 Section: ldiv() [prindle.xsh-107] Problem: THIS IS A CORRECTION OF [prindle.xsh-92] WHICH REFERENCED AN INCORRECT PAGE NUMBER (1294) AND CONTAINED A MISSPELLING. The wording here speaks only of the long integer quotient and ldiv_t return value. Action: Change the sentence "If the division...algebraic quotient." to: If the division is inexact, the resulting quotient is the long integer (for function ldiv()) or long long integer (for function lldiv()) of lesser magnitude that is nearest to the algebraic quotient. Change the entire RETURN VALUE section to: The ldiv() function shall return a structure of type ldiv_t, comprising both the quotient and the remainder. The structure includes the following members in any order: long quot; /* Quotient */ long rem; /* Remainder */ The lldiv() function shall return a structure of type lldiv_t, comprising both the quotient and the remainder. The structure includes the following members in any order: long long quot; /* Quotient */ long long rem; /* Remainder */ ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 227 prindle@voicenet.com Bug in XSHd4 (rdvk# 66) [prindle.xsh-31] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_229 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1206 Line: 22842-22846 Section: lgamma() Problem: These functions are incorrectly shaded and identified as XSI functionality. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). _____________________________________________________________________________ objection Enhancement Request Number 228 prindle@voicenet.com Bug in XSHd4 (rdvk# 181) [prindle.xsh-93] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Also covered by ERN 53 XSI shade 22846, 22849-22850 The sign of.. _____________________________________________________________________________ Page: 1206 Line: 22842-22871 Section: lgamma() Problem: These functions are incorrectly shaded and identified as XSI functionality. They are ISO C functions. Furthermore, with the addition of the ISO C functions tgamma*(), there is no need for the external signgam, and therefore these functions can be, and are true functions and are reentrant and thread safe. Furthermore, the overflow condition is a required ERANGE error in ISO C, not a "may"; and the underflow error is a CX. Action: Remove shading and XSI margin code from synopsis. Delete "extern int signgam;" from the synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Delete the sentence beginning on line 22849 "The sign of..." Delete the paragraph at lines 22855-22856. Change the word "may" on line 22852 to "shall". Shade lines 22864-22865 and margin code CX. Remove the word "overflow" on line 22870, and shade everything from ",or" on the previous line to "underflow." on this line and margin code CX. Add after 22066: These functions shall fail if: [ERANGE] x is too large and the value returned would have caused overflow. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). _____________________________________________________________________________ objection Enhancement Request Number 229 ajosey@opengroup.org Bug in XSHd4 lgamma (rdvk# 2) {tog.aug14.5} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1206 Line: 22842 Section: lgamma Problem: The lgamma() function is part of the C standard Action: Remove the XSI shading from the complete synopsis block. Add to CH The lgamma() function is no longer XSI shaded. _____________________________________________________________________________ objection Enhancement Request Number 230 prindle@voicenet.com Bug in XSHd4 (rdvk# 184) [prindle.xsh-96] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1223 Line: 23462-23463 Section: localtime() Problem: How the timezone and DST used by this function get set are implementation defined in ISO C. The sentence on these lines is a CX. Action: Shade last sentence of this paragraph and mark with margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 231 prindle@voicenet.com Bug in XSHd4 (rdvk# 185) [prindle.xsh-97] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1224 Line: 23522 Section: localtime() Problem: The function gettimeofday() returns an int and deals with no static object. It seems unreasonable that a call to gettimeofday() be allowed to overwrite information returned by the other functions. It is, in fact, a thread-safe function. Action: Remove gettimeofday() from this list, as it does (or should) not do what this line says it does. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 232 prindle@voicenet.com (rdvk# 190) [prindle.xsh-98] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Just add the C disclaimer block in the action. This is also covered by ERN 53 _____________________________________________________________________________ Page: 1233 Line: 23782 Section: log1p() Problem: These functions are incorrectly shaded and identified as XSI functionality. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 233 ajosey@opengroup.org Bug in XSHd4 (rdvk# 79) {tog.sep4.112} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 1233 Line: 23787 Section: log1p Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 23787 and 23794 _____________________________________________________________________________ editorial Enhancement Request Number 234 ajosey@opengroup.org Bug in XSHd4 log1p (rdvk# 6) {tog.aug14.6} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1233 Line: 23812 Section: log1p Problem: missing change history Action: Add to CH The log1p() function is no longer XSI shaded. _____________________________________________________________________________ objection Enhancement Request Number 235 ajosey@opengroup.org Bug in XSHd4 (rdvk# 78) {tog.sep4.13} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE See ERN 53 _____________________________________________________________________________ Page: 1234 Line: 23832 Section: log2 Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 23832 and 23839 _____________________________________________________________________________ objection Enhancement Request Number 236 prindle@voicenet.com (rdvk# 191) [prindle.xsh-99] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_237 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1235 Line: 23857-23860 Section: logb() Problem: These functions are incorrectly shaded and identified as XSI functionality. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 237 ajosey@opengroup.org Bug in XSHd4 logb (rdvk# 5) {tog.aug14.7} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1235 Line: 23857 Section: logb Problem: the logb() function is part of the C standard and should not be XSI shaded Action: Remove the XSI shading from the complete synopsis block Add to CH The logb() function is no longer XSI shaded. [Ed recommendation: Accept as marked, as above, but add the ISO C disclaimer block] _____________________________________________________________________________ objection Enhancement Request Number 238 prindle@voicenet.com (rdvk# 192) [prindle.xsh-100] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: see p226 of c99 for a better description _____________________________________________________________________________ Page: 1235 Line: 23865 Section: logb() Problem: An ISO C requirement is missing here, regarding normalization. Action: Add after 23865: If x is subnormal it is treated as though it were normalized; thus, for positive finite x, 1 [LEQ] x [TIMES] FLT_RADIX [TO-THE-POWER] -logb(x) < FLT_RADIX ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 239 prindle@voicenet.com (rdvk# 193) [prindle.xsh-101] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take first change below, _____________________________________________________________________________ Page: 1236 Line: 23898-23924 Section: longjmp() Problem: ISO C has an inconsistency in which, in one breath it allows setjmp() to be either a macro or function (but does not allow a macro definition, if there is one, to be overridden), and in the next breath, consistently refers only to the setjmp() macro. Action: You seem to have corrected that here but for one place, so: Change "the setjmp() macro" on line 23903 to just "setjmp()". But I'm not sure of the shading implications here. By deleting all occurrences of "the setjmp() macro", you are changing the requirement on longjmp() because the current wording in ISO C does not require it to work correctly if the environment was saved with the setjmp() function, whereas our wording does. Should an interpretation request be filed against ISO C, or should we shade all occurrences of setjmp() here, mark them CX, and add a note to explain the inconsistency in the ISO standard? ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 240 prindle@voicenet.com (rdvk# 194) [prindle.xsh-102] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1236 Line: 23909-23909 Section: longjmp() Problem: Some words were inadvertently transposed here, which results in not only a deviation from ISO C, but an unparsable sentence. Action: Replace - "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)," with - "All accessible objects have values, and all other components of the abstrct machine have state (for example, floating-point status flags and open files), as of the time longjmp() was called," ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 241 prindle@voicenet.com (rdvk# 195) [prindle.xsh-103] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1236 Line: 23915-23918 Section: longjmp() Problem: I cannot find anywhere in ISO C where this "more async safe" behavior is specified. As fallout from ISO C 7.1.4 paragraph 4, and without an exception to the contrary for longjmp(), ISO C's longjmp() does not appear to be async safe. The fact that we've required it to be so down to the first level of nesting would appear to be an extension. Action: Shade this paragraph and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 242 prindle@voicenet.com (rdvk# 197) [prindle.xsh-105] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1288 Line: 25500 Section: mmap() Problem: Margin code is displaced up one line. Action: Place margin code on this shaded line. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 243 prindle@voicenet.com Bug in XSHd4 (rdvk# 180) Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1294 Line: 22796-22807,22810-22813 Section: ldiv() [prindle.xsh-92] Problem: The wording here speaks only of the long integer quotient and ldiv_t return value. Action: Change the sentence "If the division...algebraic quotient." to: If the division is inexact, the resulting quotient is the long integer (for function ldiv()) or long long integer (for function lldiv()) of lesser magnitude that is nearest to the algebraic quotient. Change the entire RETURN VALUE section to: The ldiv() function shall return a structure of type ldiv_t, comprising both the quotient and the remainder. The structure includes the following members in any order: long quot; /* Quotient */ long rem; /* Remainder */ The lldiv() function shall return a structure of type lldiv_t, comprising both the quotient and the remainder. The structure includes the following members in any order: long long quot; /* Quotient */ ling long rem; /* Remainder */ [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 244 prindle@voicenet.com (rdvk# 198) [prindle.xsh-106] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1294 Line: 25758 Section: modf() Problem: The wording here speaks only of the double pointed to by iptr. Action: Change the sentence "It stores...by iptr" to: It stores the integral part as a double (for function modf()), a float (for function modff()), or a long double (for function modfl()), in the object pointed to by iptr. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 245 prindle@voicenet.com (rdvk# 200) [prindle.xsh-108] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review team disagrees with the problem statement because Ulrich says its not needed. _____________________________________________________________________________ Page: 1306 Line: 26115-26116 Section: mq_receive() Problem: As I understand it, if a function: a) has more than one argument that is a pointer b) stores some data by derereferencing at least one pointer argument c) is not guaranteed to work if an output buffer (as in b) overlaps any other buffer referenced by a pointer argument Then all the pointer arguments to that should have the restrict qualifier in its prototype. The two pointers are both to output buffers, so no implementation of this function could be expected to work correctly if the buffers overlapped. If this is true, then this function needs restrict qualifiers added to its prototype, both on its man page and on the associated header page in XBD. Action: Add the restrict qualifier to each of the pointer arguments passed on the line noted above. Fix the header page too. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 246 prindle@voicenet.com (rdvk# 290) [prindle.xsh-136] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1306 Line: 26151-26152 Section: mq_receive() Problem: See also page 1309 line 26248-26249 section mq_send() See also page 1595 line 34144-35145 section pthread_mutex_timedlock() See also page 1765 line 39098-39099 section sem_timedwait() The sentence (up to the semicolon) beginning with "If the timers..." is dependent on the TMR option. Action: Margin code these sentences only: TMO TMR for mq_receive() and mq_send(), TMR for pthread_mutex_timedlock() and sem_timedwait(). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 247 ajosey@opengroup.org Bug in XSHd4 (rdvk# 77) {tog.sep4.14} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 1338 Line: 27056 Section: nearbyint Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 27056 and 27059 _____________________________________________________________________________ objection Enhancement Request Number 248 ajosey@opengroup.org Bug in XSHd4 nextafter (rdvk# 8) {tog.aug14.8} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the Ed recommendation _____________________________________________________________________________ Page: 1339 Line: 27075 Section: nextafter Problem: the nextafter family of functions are part of the C standard and should not be XSI shaded Action: Remove the XSI shading from the complete synopsis block Add to CH The nextafter() function is no longer XSI shaded. and remove nextafter from the list of functions added on line 27124 [Ed recommendation: Accept as marked. as above, but add the ISO C disclaimer block] _____________________________________________________________________________ objection Enhancement Request Number 249 prindle@voicenet.com (rdvk# 201) [prindle.xsh-109] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove "double-precision" on 27074, 27089, 27098. 27096, 27101 change "nextafter" to "these functions". _____________________________________________________________________________ Page: 1339 Line: 27093 Section: nextafter() value in the specified format Problem: The wording here speaks only of returning a double. Action: Change the phrase "double-precision floating-point value" to "value in the specified format" ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 250 ajosey@opengroup.org Bug in XSHd4 (rdvk# 76) {tog.sep4.15} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: OBE see ERN 53 _____________________________________________________________________________ Page: 1339 Line: 27101 Section: nextafter Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 27101 and 27108 _____________________________________________________________________________ comment Enhancement Request Number 251 prindle@voicenet.com (rdvk# 202) [prindle.xsh-110] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1345 Line: 27278 Section: nice() Problem: The SEE ALSO list should have references to 2 closely related functions. Action: Add getpriority() and setpriority() to the SEE ALSO list. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 252 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 282) [DWC-678] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1369 Line: 27949 Section: perror Problem: (perror(): character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P1369, L27949 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 253 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 275) [DWC-671] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1369 Line: 27950 Section: perror Problem: (perror(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character." on P1369, L27950 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 254 prindle@voicenet.com (rdvk# 203) [prindle.xsh-111] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make the following changes to poll.h to make it less STREAMS specific, and to poll() to partition the STREAMS specific semantics. This formalizes the concept of three classes of data for poll to read/write: normal, priority and high-priority data which presently exist on the poll() man page. Note that the wording of some of these descriptions has been aligned with that on the poll() man page. poll.h Change the flags for the events and revents members of the pollfd structure: POLLIN Data other than high-priority data may be read without blocking POLLRDNORM Normal Data may be read without blocking POLLRDBAND Priority data may be read without blocking. POLLPRI High-priority data may be read without blocking. POLLOUT Same value as POLLWRNORM. POLLWRNORM Normal data may be written without blocking POLLWRBAND Priority Data may be written. POLLERR An error has occurred (revents only). POLLHUP Device has been disconnected (revents only). POLLNVAL Invalid fd member (revents only). Add at the end of this: "The significance and semantics of normal, priority and high-priority data are file and device-specific." On the poll() man page: POLLIN Data other than high-priority data may be read without blocking . [XSR] For STREAMS, this flag is set in revents even if the message is of zero length. This flag shall have the same effect as POLLRDNORM | POLLRDBAND. POLLRDNORM Normal Data may be read without blocking [XSR] For STREAMS, data on priority band 0 may be read without blocking. This flag is set in revents even if the message is of zero length. POLLRDBAND Priority data may be read without blocking. [XSR] For STREAMS, data on priority bands greater than 0 may be read without blocking. This flag is set in revents even if the message is of zero length. POLLPRI High-priority data may be read without blocking. [XSR] For STREAMS, this flag is set in revents even if the message is of zero length. POLLOUT Normal data may be written without blocking [XSR] For STREAMS, data on priority band 0 may be written without blocking. POLLWRNORM Same as POLLOUT. POLLWRBAND Priority Data may be written. [XSR] For STREAMS, data on priority bands greater than 0 may be written without blocking. This event only examines bands that have been written to at least once. POLLERR An error has occurred on the device or stream. This flag is only valid in the revents bitmask; it shall be ignored in the events bitmask. POLLHUP The device has been disconnected. This event and POLLOUT are mutually exclusive; a stream can never be writable if a hangup has occurred. However this event and POLLIN, POLLRDNORM, POLLRDBAND, or POLLPRI are not mutually-exclusive. This flag is only valid in the revents bitmask; it shall be ignored in the events bitmask. POLLNVAL The specified fd value is invalid. This flag is only valid in the revents bitmask; it shall be ignored in the events bitmask. Add a new para at the end of the flags: "The significance and semantics of normal, priority and high-priority data are file and device-specific." _____________________________________________________________________________ Page: 1373-1376 Line: 28050-28193 Section: poll() Problem: This man page is seriously unusable as it stands, except for options POLLIN, POLLOUT, and POLLERR. Other options refer to "priority bands" (which are strictly a STREAMS concept) without being flagged XSR, and to "high-priority data" which is TOTALLY undefined anywhere in XBD or XSH. I know it's out of a former incarnation of .1g with XTI therein, but I didn't understand it there either (except for the obvious POLLIN, POLLOUT, POLLERR parallels to select()). Action: I can barely begin to suggest how to fix this up - at least all discussion of "priority bands" needs to be shaded/coded XSR, and all discussion of "high-priority data" needs to be either deleted or a definition of what exactly this is needs to be added to XBD. Also, in here references to STREAMS are shaded and coded, but references to pseudo-terminals aren't, though elsewhere in the document they are also coded XSR. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 255 ajosey@opengroup.org Bug in XSHd4 (rdvk# 27) {tog.aug21.3} Mon, 21 Aug 2000 11:57:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1380 Line: 28302 Section: posix_fadvise Problem: The functions within the options, _POSIX_ADVISORY_INFO, _POSIX_CLOCK_SELECTION, _POSIX_CPUTIME, _POSIX_MONOITONIC_CLOCK, _POSIX_SPAWN, _POSIX_SPORADIC_SERVER, _POSIX_TIMEOUTS and _POSIX_TYPED_MEMORY_OBJECTS are part of the Advanced Realtime option and the NAME section needs marking accordingly. Action: Add (ADVANCED REALTIME) to the end of the NAME line the following functions: posix_fadvise posix_fallocate posix_memalign posix_madvise pthread_condattr_getclock pthread_condattr_setlock clock_nanosleep clock_getcpuclockid posix_spawn*() posix_mem_offset() posix_typed_mem*() mq_timedreceive() mq_timedsend() pthread_mutex_timedlock() sem_timedwait() spawn.h (change REALTIME to ADVANCED REALTIME) [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 256 prindle@voicenet.com (rdvk# 204) [prindle.xsh-112] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_257 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1389 Line: 28549-28557 Section: posix_spawn() Problem: Inconsistent application of restrict keyword. Action: Add restrict to 3rd pointer arg of both prototypes, and 5th and 6th pointer arg of second prototype. Fix also on pointer page and on page in XBD. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 257 drepper@redhat.com Bug in XSHd4 posix_spawn (rdvk# 24) {ud-4} Mon, 21 Aug 2000 05:47:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1389 Line: 28549-28557 Section: posix_spawn() Problem: A few too many restrict slipped in which were not in my proposal. One cannot in general say anything about the strings, they might overlap. Action: The types of the argv and envp parameters should be char *const[restrict] I.e., the restrict after the * in all four cases should go away. [Ed recommendation: Accept (note this applies to posix_spawn() and posix_spawnp() ] _____________________________________________________________________________ comment Enhancement Request Number 258 prindle@voicenet.com (rdvk# 205) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 1397 Line: 28907-28913 Section: posix_spawn_file_actions_addclose() [prindle.xsh-113] Problem: I agree with the note, I don't like the words, they specify implementation, not requirements. Action: Add in place of this note, an additional sentence to the previous paragraph: Changes to the string pointed to by path after this function returns shall not affect the path name of the file to be opened when a new process is spawned using this file actions object. N.B.: does this require an interp request, and did we do one? ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 259 prindle@voicenet.com (rdvk# 206) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_210 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1404 Line: 29084-29092 Section: posix_spawn_file_actions_init() [prindle.xsh-114] Problem: THIS IS ANOTHER INSTANCE OF THE PROBLEM FOUND IN [prindle.xsh-84]. Not clear that this page should be here. I thought the rule was if a function's name immediately alphabetically follows the previous function and it is described on the previous function's page, a pointer page was not necessary. Action: Delete this pointer page. [unless the rules have changed] I had previously noted in [prindle.xsh-84] that pthread_barrierattr_init() did not have a pointer page. This was incorrect, it does have a pointer page and that page does not immediately follow pthread_barrierattr_destroy(), so all is well with that function. We need to pick one rule [I don't care what] and use it everywhere. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 260 prindle@voicenet.com (rdvk# 207) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1407 Line: 29170-29171 Section: posix_spawnattr_getflags() [prindle.xsh-115] Problem: Misalignment between margin code and shading. Action: Line them up. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 261 prindle@voicenet.com (rdvk# 208) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1407 Line: 29171-29173 Section: posix_spawnattr_getflags() [prindle.xsh-116] Problem: The sentence "In addition...also be supported." is redundant. The concept is captured immediately before with shading and margin coding. Action: Delete this sentence. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 262 ajosey@opengroup.org Bug in XSHd4 (rdvk# 29) {tog.aug21.1} Mon, 21 Aug 2000 11:57:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1427-1471 Line: 29520 Section: posix_trace_attr_destroy Problem: The posix_trace*() functions are part of the TRACING option group (an XSI option) and the NAME section needs to be marked accordingly for these functions. Action: Add (TRACING) to the end of the NAME line for all the posix_trace*() functions. [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 263 prindle@voicenet.com (rdvk# 209) [prindle.xsh-117] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1432 Line: 29707-29711,29714-29715 Section: posix_trace_attr_getinherited() Problem: These lines are dependent on the TRL option, but not shaded. Action: Shade these lines and margin code with TRL. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 264 prindle@voicenet.com (rdvk# 212) [prindle.xsh-120] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1442 Line: 29967 Section: posix_trace_create() Problem: This function is not under the TRL option, but also has functionality in the base TRC option. It needs to revert to TRC margin code. Action: Add TRC margin code on this line. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 265 prindle@voicenet.com (rdvk# 210) [prindle.xsh-118] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1443 Line: 30031 Section: posix_trace_create() Problem: The margin code on this line should revert back to TRL. Action: Margin code this line TRL. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 266 prindle@voicenet.com (rdvk# 211) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1444 Line: 30059-30070 Section: posix_trace_create() [prindle.xsh-119] Problem: These lines are not conditional on the TRL option (as reverted on line 30031 per [prindle.xsh-118]), but are available within the base TRC option. They are also logically out of place, as the base functionality of posix_trace_shutdown() needs to be described before the functionality unique to a trace log. Action: Remove shading on these lines and move the 3 paragraphs immediately before line 30050. Then add margin code TRL on the current line 30050 to resume the log functionality description, but now talking about posix_trace_shutdown(). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 267 prindle@voicenet.com Bug in XSHd4 (rdvk# 168) Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1446 Line: 30128-30129 Section: posix_trace_event() [prindle.xsh-80] Problem: The function posix_trace_eventid_open() has no pointer page where it should alphabetically appear in the man pages (i.e. before page 1450). Action: Add pointer page for posix_trace_eventid_open() back to this page. _____________________________________________________________________________ comment Enhancement Request Number 268 prindle@voicenet.com (rdvk# 213) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 1448-1449 Line: 30206-30265 Section: posix_trace_eventid_equal() [prindle.xsh-121] Problem: I am at a total loss to explain why posix_trace_trid_eventid_open() is part of the TEF (trace event filtering) option. It is specified that way in .1q, but that doesn't mean it's right. I can't find rationale for why it is so. Action: Check this with Francois Riche. If this function should not be under that option, remove all the unnecessary shading associated with that function throughout this section, and revert only to TRC shading for all the functions in the SYNOPSIS section. Fix the pointer page and header in XBD. File an interpretation against .1q to formalize this. If this function should be under that option, "never mind". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 269 prindle@voicenet.com (rdvk# 214) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1449 Line: 30248 Section: posix_trace_eventid_equal() [prindle.xsh-122] Problem: posix_trace_eventid_get_name() is inadvertently shaded TEF. Action: Remove shading on this function name here. See also [prindle.xsh-121] regarding shading on the other function. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 270 ajosey@opengroup.org Bug in XSHd4 (rdvk# 12) {tog.aug14.11} Mon, 14 Aug 2000 15:28:33 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1449 Line: 30261 Section: posix_trace_eventid_equal Problem: The text currently says The posix_trace_eventid_get_name( ) and posix_trace_trid_eventid_open( ) functions may fail if: | [EINVAL] The trid argument was not a valid trace type identifier. The trid argument is a trace stream identifier, not a trace type identifier Action: Change "trace type identifier" to "trace stream identifier" [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 271 prindle@voicenet.com (rdvk# 218) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1460 Line: 30529 Section: posix_trace_getnext_event() [prindle.xsh-126] Problem: Margin coding is incorrect. Action: Revert back to margin code "TRC" on this line. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 272 prindle@voicenet.com (rdvk# 291) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_273 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1460 Line: 30558-30561 Section: posix_trace_getnext_event() [prindle.xsh-137] Problem: NOTE: THIS IS A CORRECTION TO [prindle-xsh.123] The TMO margin code should restart on line 30555, not line 30558 as stated in [prindle-xsh.123]. Otherwise, line 30561 still needs to be fixed as stated therein. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 273 prindle@voicenet.com (rdvk# 215) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1460 Line: 30558-30561 Section: posix_trace_getnext_event() [prindle.xsh-123] Problem: The margin coding here is off. Action: Line 30558: margin code TMO. Line 30561: remove margin code as it is a continuation of the shading above (TMO). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 274 prindle@voicenet.com (rdvk# 216) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigenda or resolution from the appropriate body. _____________________________________________________________________________ Page: 1461 Line: 30596-30608 Section: posix_trace_getnext_event() [prindle.xsh-124] Problem: I will note that here, and in a large number of other trace functions, all the errors are of the "may fail" flavor, even though equivalent errors, when they can occur in other POSIX functions, are of the "shall fail" flavor. I believe this is unintentional, and is a result of the phrase "If the following condition(s) is(are) detected" being used in the .1q standard instead of the phrase "If the following condition(s) occur(s)", as the result of a cut-and-paste error during document development, and going undetected by the ballot group. Notice for example that the error on line 30606 [ETIMEDOUT], if not detected by posix_trace_timedgetnext_event(), renders that function entirely useless for its intended purpose!!! Action: Check with Francois Riche on this. If it is in error, an interpretation needs to be filed (I'm almost positive this is an error). If interp is filed and this is declared an error, fix it by changing all the "may fail"s that are identified by the interpretation resolution as incorrect to "shall fail"s. This applies to every trace_*() function, not just this one; the bug is rather pervasive. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 275 prindle@voicenet.com (rdvk# 217) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1471 Line: 30723 Section: posix_trace_trygetnext_event() [prindle.xsh-125] Problem: Margin coding is incorrect. Action: Change margin code from "TRC TMO" to "TRC". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 276 prindle@voicenet.com (rdvk# 219) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being handled by the revision to the error handling being applied globally to all the maths functions. _____________________________________________________________________________ Page: 1477 Line: 30913-30915,30919,30912 Section: pow() [prindle.xsh-127] Problem: The same error condition is described as being handled two different ways. Action: Delete lines 30913-30914 (they conflict with ISO C). Shade "0 is returned and" on line 30915 and margin code CX. Delete line 30919 (it conflicts with ISO C). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 277 drepper@redhat.com Bug in XSHd4 pselect (rdvk# 22) {ud-6} Mon, 21 Aug 2000 05:47:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1481 Line: 30966-30968 Section: pselect() Problem: The pselect function has no restrict qualifiers. Action: Change lines 30966-30968 to: int pselect(int nfds, fd_set *restrict readfds, fd_set *restrict writefds, fd_set *restrict errorfds, const struct timespec *restrict timeout, const sigset_t *restrict sigmask); [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 278 prindle@voicenet.com (rdvk# 220) [prindle.xsh-128] Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See tog.sep23.1, pseudo-terminals need not be implemented using STREAMS _____________________________________________________________________________ Page: 1481 Line: 30988-30989 Section: pselect() Problem: Pseudo-terminal devices are part of the STREAMS option XSR. This has been established in open() and close(). Action: Shade "and pseudo-terminal devices" and include in the XSR margin code. [Ed recommendation: REJECT. This is incorrect and the fixes to open() and close() were identified in tog.sep23.1] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 279 prindle@voicenet.com (rdvk# 221) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1481-1483 Line: 31003-31025,31029-31087 Section: pselect() [prindle.xsh-129] Problem: >From line 31003 onward, with the exception of 31026-31028, there are many instances where the function name pselect() or the function name select() is used alone, but where the requirements apply to either function. Action: In these ranges of lines, find every occurence of "pselect()" by itself, or "select()" by itself, and change it to "pselect() or select()". [Ed recommendation: Accept (but this really is editorial given line 30980)] ------------------------------------------------------------------------------- ______________________________________________________________________________ comment Enhancement Request Number 280 David.Butenhof@compaq.comBug in XSHd4 pthread_attr_setinheritsched (rdvk# 97) {drb.xshd4.003} Mon, 11 Sep 2000 17:38:00 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Select alternative 2 of the action ______________________________________________________________________________ Page: 1495 Line: 31457,31460 Section: pthread_attr_setinheritsched Problem: The specification, (as does POSIX 1003.1-1996), says only that the inheritsched attribute specifies the inheritance of "the scheduling policy and associated attributes". While I believe there is no actual ambiguity in POSIX 1003.1-1996, given how the "associated attributes" are defined, I'm less convinced that there's no real ambiguity in the new format. Furthermore, it would always have been better to have the affected attributes spelled out rather than implied. I would like to see this page give a list of the associated standard attributes. Those are, I believe, schedpolicy, schedparams, and contentionscope. In particular, I have in the past seen some confusion regarding whether contention scope is or is not one of the inherited attributes. Scope must be included for two reasons: 1) Because the only definition of "thread scheduling attributes" occurs in 1003.1-1996 on page 298, section 13.4.1, and this section defines the schedpolicy, schedparams, and contentionscope attributes. 2) Because many systems must place limitations (e.g., privilege) on the policy and priority values for SYSTEM contention scope that do not apply for PROCESS contention scope. Failing to switch between the "explicit" and "inherited" contention scope when switching policy and priority would result in unsupportable combinations. This is a "comment" because while it's a little more than just an "editorial" issue, I don't think it merits an "objection". I am suggesting merely that the necessary interpretation be made more clear to readers (both application developers and implementors). Action: Replace the phrase "scheduling policy and associated attributes" on lines 31457 and 31460 with the phrase "scheduling policy, scheduling parameters, and contention scope". OR Provide a new paragraph explaining the phrase "thread scheduling attributes" (a phrase already used on lines 31458 and 31461), such as: The following "thread scheduling attributes" defined by the standard are affected by the inheritsched attribute: scheduling policy (schedpolicy), scheduling parameters (schedparams), and scheduling contention scope (contentionscope). With such an introduction, the phrase on lines 31457 and 31460 would be reduced to "thread scheduling attributes". _____________________________________________________________________________ objection Enhancement Request Number 281 prindle@voicenet.com (rdvk# 222) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: **NOTE THAT THIS IS A CROSS VOLUME CHANGE ** _____________________________________________________________________________ Page: 1503 Line: 31642 Section: pthread_attr_getstack() [prindle.xsh-130] Problem: These functions are supposed to be prototyped in . They are not. Action: Add these prototypes into in XBD, shading them XSI. [Ed recommendation: ACCEPT **NOTE THAT THIS IS A CROSS VOLUME CHANGE **] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 282 drepper@redhat.com Bug in XSHd4 pthread_attr_getstack() (rdvk# 98) {ud-5} Mon, 11 Sep 2000 19:22:13 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1503 Line: 31643-31644 Section: pthread_attr_getstack() Problem: The restrict keyword wasn't added for this functions. Action: Replace the lines with: int pthread_attr_getstack(const pthread_attr_t *restrict attr, void **restrict stackaddr, size_t *restrict stacksize); [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 283 David.Butenhof@compaq.com Bug in XSHd4 pthread_attr_setstack (rdvk# 95) {drb.xshd4.002} Mon, 11 Sep 2000 16:09:55 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1503 Line: 31655 Section: pthread_attr_setstack Problem: An "&" (ampersand) character has been omitted, or possibly swallowed as a text formatting command during processing. As an example of an alignment check in the pthread_attr_setstack function, I wrote the C fragment "if (stackaddr & 0x7)". In the draft, this appears as "if (stackaddr 0x7)" which is not C, nor particularly informative. Action: Take whatever editorial steps are required to restore the ampersand operator. [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 284 David.Butenhof@compaq.com Bug in XSHd4 pthread_attr_setstackaddr (rdvk# 96) {drb.xshd4.004} Mon, 11 Sep 2000 18:00:17 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 1. Mark this man page Obsolescent (add OB to the synopsis] 2. Add pthread_attr_setstack, pthread_attr_getstack to the SEE ALSO line 3. Add to APPLICATION USAGE, as suggested in the rdvk 4. Add a note to Change History that the page is now marked obsolescent. _____________________________________________________________________________ Page: 1505 Line: 31704 Section: pthread_attr_setstackaddr Problem: With the introduction in draft for of pthread_attr_setstack, I would prefer to see a "note" added to pthread_attr_setstackaddr directing developers towards the new and improved interface. Otherwise, many developers unfamiliar with the Austin process are unlikely to notice it. This does not affect the correctness of the standard, merely its "ease of use". Action: Add a new paragraph following line 31704 such as: Note: There are various ambiguities in the specification of this interface. Among these is the question of whether the address value represents the initial stack pointer for the created thread, or the base (low) address of the stack. (And in the latter case there is even more ambiguity regarding the determination of the stack's size.) IEEE Std. 1003.1-200x has introduced the new interfaces pthread_attr_setstack() and pthread_attr_getstack() to eliminate these ambiguities, and use of the new interfaces will result in more portable code. [Ed recommendation: Accept as marked, 1. Mark this man page Obsolescent (with OB) on the synopsis 2. Add pthread_attr_setstack, pthread_attr_getstack to the SEE ALSO line 3. Add to APPLICATION USAGE, as suggested in the rdvk, although I'm not sure I like the wording quite , but do not have a suggested replacement yet 4. Add a note to Change History that the page is now marked obsolescent.] _____________________________________________________________________________ editorial Enhancement Request Number 285 ajosey@opengroup.org Bug in XSHd4 (rdvk# 28) {tog.aug21.2} Mon, 21 Aug 2000 11:57:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1517 Line: 31857 Section: pthread_barrier_destroy Problem: The functions within the options, _POSIX_BARRIERS, _POSIX_SPIN_LOCKS, _POSIX_THREAD_CPUTIME, and _POSIX_THREAD_SPORADIC_SERVER are part of the Advanced Realtime Threads options and the NAME section needs marking accordingly. Action: Add (ADVANCED REALTIME THREADS) to the end of the NAME line the following functions: (pthread_barrier*, pthread_spin*) page 1517, line 31857 page 1519, line 31919 page 1520, line 31928 page 1522, line 31980 page 1524, line 32025 page 1526, line 32075 page 1527, line 32083 page 1647, line 35524 page 1649, line 35583 page 1650, line 35591 page 1652, line 35634 page 1653, line 35642 on page 1568, pthread_getcpuclockid change the "REALTIME" on line 33254 to "ADVANCED REALTIME THREADS" [Ed recommendation: Accept] _____________________________________________________________________________ Comment Enhancement Request Number 286 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 332) [DWC-805] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1536 Line: 32401-32421 Section: pthread_cond_broadcast Problem: (pthread_cond_broadcast(): rationale) The statement on L32415: cond->value++; /* 3 */ cannot be executed after the statement on L32414: pthread_mutex_lock(cond->mutex); /* 2 */ until the code on L32403: pthread_mutex_unlock(mutex); /* 9 */ being executed since pthread_mutex_lock(cond->mutex) will block until pthread_mutex_unlock(mutex) releases the mutex. Action: Change the example on P1536, L32401-43421 to: pthread_cond_wait(mutex, cond): value = cond->value; /* 1 */ pthread_mutex_unlock(mutex); /* 2 */ pthread_mutex_lock(cond->mutex); /* 10 */ if (value == cond->value) { /* 11 */ me->next_cond = cond->waiter; cond->waiter = me; pthread_mutex_unlock(cond->mutex); unable_to_run(me); } else pthread_mutex_unlock(cond->mutex); /* 12 */ pthread_mutex_lock(mutex); /* 13 */ pthread_cond_signal(cond): pthread_mutex_lock(cond->mutex); /* 3 */ cond->value++; /* 4 */ if (cond->waiter) { /* 5 */ sleeper = cond->waiter; /* 6 */ cond->waiter = sleeper->next_cond; /* 7 */ able_to_run(sleeper); /* 8 */ } pthread_mutex_unlock(cond->mutex); /* 9 */ ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 287 prindle@voicenet.com (rdvk# 224) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1551 Line: 32841-32850 Section: pthread_condattr_getclock() [prindle.xsh-132] Problem: The word "clock" wherever it appears in the phrase "clock attribute" should be italicized (as the name of an attribute), but is not. Action: Italicize each "clock" that appears in the noun phrase "clock attribute". ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 288 prindle@voicenet.com (rdvk# 223) Fri, 22 Sep 2000 16:04:32 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Do the change , but do we need shading? _____________________________________________________________________________ Page: 1553 Line: 32898-32899 Section: pthread_condattr_getpshared() [prindle.xsh-131] Problem: This paragraph is out of context, and is incorrect in this context, since it ignores the clock attribute. The paragraph correctly appears on page 1549, but is incomplete there because it still lacks sufficient context. Action: Delete this paragraph here. Insert this sentence before lines 32801-32802 on page 1549: This volume of xxx requires two attributes, the clock attribute and the process-shared attribute. [clock and process-shared in italics] ------------------------------------------------------------------------------- [Ed note: will this require shading?] _____________________________________________________________________________ objection Enhancement Request Number 289 drepper@redhat.com Bug in XSHd4 pthread_create() (rdvk# 23) {ud-5} Mon, 21 Aug 2000 05:47:49 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1558 Line: 32964 Section: pthread_create() Problem: My restrict proposal missed one place in the pthread_create() prototype. Action: Change the type of the fourth parameter to void *restrict arg [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 290 drepper@redhat.com Bug in XSHd4 pthread_exit() (rdvk# 92) {ud-3} Tue, 5 Sep 2000 19:26:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete line 33170 Change "cannot" to "shall not" on line 33167 _____________________________________________________________________________ Page: 1564 Line: 33170 Section: pthread_exit() Problem: The pthread_exit() function obviously must never return which is also stated in line 33167. But why is then the sentence in line 33170 necessary which says The pthread_exit() function shall not return an error code of EINTR. Action: Remove line 33170. _____________________________________________________________________________ comment Enhancement Request Number 291 prindle@voicenet.com (rdvk# 287) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1571 Line: 33384-33386 Section: pthread_getspecific() [prindle.xsh-133] Problem: There is no indication in the change history of the interpretation that supports this requirement (which is not in 1003.1-1996). Action: Document the source of this new requirement as: IEEE PASC Interpretation 1003.1c #3 (Part 6) is applied, updating the DESCRIPTION. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 292 prindle@voicenet.com (rdvk# 288) [prindle.xsh-134] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1571 Line: 33386 Section: pthread_getspecific() Problem: Period in the wrong place. Action: Change "pthread_setspecific.()" to "pthread_setspecific()." [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 293 Dave.Butenhof@compaq.com Bug in XSHd4 pthread_setspecific (rdvk# 160) {drb.xshd4.005} Mon, 18 Sep 2000 12:33:34 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1571 Line: 33386 Section: pthread_setspecific Problem: A few words were dropped from a sentence here, resulting in the awkward phrase "Calling pthread_setspecific() thread-specific data destructor routine may result either in lost storage (after at least PTHREAD_DESTRUCTOR_ITERATIONS) or an infinite loop." The parenthetical note also feels rather too brief, leading to the unavoidable question "iterations of what?" Action: The sentence should read: Calling pthread_setspecific() from a thread-specific data destructor routine may result either in lost storage (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or in an infinite loop. [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 294 prindle@voicenet.com (rdvk# 289) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1588 Line: 33952 Section: pthread_mutex_getprioceiling() [prindle.xsh-135] Problem: This line says "change the priority ceiling...", while both get and set functions are described below. Action: Change the word "change" to "get and set". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 295 prindle@voicenet.com (rdvk# 293) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1605 Line: 34482-34483 Section: pthread_mutexattr_getprotocol() [prindle.xsh-139] Problem: Margin coding is off here. Action: Line 34482 should be coded TPI, line 34483 should be coded TPP. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 296 prindle@voicenet.com (rdvk# 294) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Reject, since the whole man page is already under TPP|TPI shading in the SYNOPSIS _____________________________________________________________________________ Page: 1605 Line: 34494-34502 Section: pthread_mutexattr_getprotocol() [prindle.xsh-140] Problem: These paragraphs have no meaning unless one of the other protocols is supported. Action: Shade them and margin code TPP|TPI. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 297 prindle@voicenet.com (rdvk# 296) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Do the change as noted below here, and also on page 1615 line 34705 (the ptr page) _____________________________________________________________________________ Page: 1609 Line: 34596 Section: pthread_mutexattr_gettype() [prindle.xsh-142] Problem: See also page 1615 line 34705 section pthread_mutexattr_settype() The page description is misleading. This interface does not affect a mutex, only a mutex attributes object. Action: Change "a mutex type" to "mutex type attribute". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 298 prindle@voicenet.com (rdvk# 295) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1610 Line: 34664 Section: pthread_mutexattr_gettype() [prindle.xsh-141] Problem: Missing space, and possible font problem. Action: Add space between "const" and "pthread...". Check usage of font here, it doesn't seem right for the argument to have two fonts. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 299 prindle@voicenet.com (rdvk# 297) [prindle.xsh-143] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the reviewers note Add the error below as a may fail delete line 34740 Add CH The EINVAL error is added as a may fail case for if either argument is invalid. _____________________________________________________________________________ Page: 1616 Line: 34735-34739 Section: pthread_once() Problem: I'll buy into this if it is made a "may fail". Like pthread_getspecific(), I think it important to allow implementations to keep this efficient, especially when it results in no action (in which case, it certainly wouldn't be necessary to determine the validity of the init_routine address). Action: Add a may-fail type error: [EINVAL] Either once_control or init_routine is invalid. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 300 prindle@voicenet.com (rdvk# 298) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1619 Line: 34839-34843 Section: pthread_rwlock_destroy() [prindle.xsh-144] Problem: I'm confused. This appears to have already been done. Action: Delete the reviewer's note. ------------------------------------------------------------------------------- [Ed note: the may fail currently there is for attr (not rwlock)] _____________________________________________________________________________ comment Enhancement Request Number 301 prindle@voicenet.com (rdvk# 299) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change p 1619line 34861 to "The margin code in the SYNOPSIS is changed to THR to indicate that the functionality is now part of the Threads option (previously it was part of the Reader/Writer locks option in 1003.1j and also part of the XSI extension ). The initializor macro is also deleted from the SYNOPSIS." Change as a separate bullet not under the 1j specific changes : p 1622 line 34948 p 1629 line 35136 p 1631 line 35189 p 1634 line 35246 "The margin code in the SYNOPSIS is changed to THR to indicate that the functionality is now part of the Threads option (previously it was part of the Reader/Writer locks option in 1003.1j and also part of the XSI extension ). " p 1636 l 35300 "The margin code in the SYNOPSIS is changed to THR TSH to indicate that the functionality is now part of the Threads option (previously it was part of the Reader/Writer locks option in 1003.1j and also part of the XSI extension ). " _____________________________________________________________________________ Page: 1619 Line: 34861 Section: pthread_rwlock_destroy() [prindle.xsh-145] Problem: See also all pthread_rwlock*() functions that follow, change history. Reference is made to the RWL margin code. No additional change history indicates that the RWL option was moved into base threads, and the RWL margin code no longer exists. Action: Update change history to indicate that the pthread_rwlock*() functionality is now required in all implementations that support threads. Reference the ERN that changed this from the POSIX (i.e. made the option non-optional if THR is supported). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 302 prindle@voicenet.com (rdvk# 300) Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Firstly start the para on 34889 on a new line Change the para as follows: delete "or SCHED_SPORADIC," on line 34891 Add new para after "acquire the lock on 34893 [Shade on TPS TSP ] If the Threads Execution Scheduling option is supported, and the threads involved in the lock are executing with the SCHED_SPORADIC scheduling policy, the calling thread.... [replicate to middle of 34893] [shade off Start the sentence "If the Thread Execution Scheduling option is not supported.." on a new para. _____________________________________________________________________________ Page: 1621 Line: 34891 Section: pthread_rwlock_rdlock() [prindle.xsh-146] Problem: See also page 1630 line 35158 section pthread_rwlock_unlock() SCHED_SPORADIC has its own suboption, TSP. Action: Margin code the word "SCHED_SPORADIC" TSP. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 303 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 344) {aj.tog.26sep.26} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This reqt is already there on line 35480 _____________________________________________________________________________ Page: 1645 Line: 35459 Section: pthread_sigmask Problem: The use of sigprocmask() is unspecified in multithreaded process (as per .1-1996) and we should say so Action: Add at the end of line 35459 "The use of sigprocmask() is unspecified in multithreaded process". _____________________________________________________________________________ Editorial Enhancement Request Number 304 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 276) [DWC-672] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1666 Line: 35996 Section: puts Problem: (puts(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character," on P1666, L35996 to ",". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 305 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 277) [DWC-673] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1666 Line: 36024 Section: puts Problem: (puts(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character," on P1666, L36024 to ",". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 306 prindle@voicenet.com (rdvk# 301) [prindle.xsh-147] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1682 Line: 36462 Section: read() Problem: Spelling error. Action: Change "connection-made" to "connection-mode". ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 307 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 278) [DWC-674] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1707 Line: 37335 Section: regcomp Problem: (regcomp(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " characters," on P1707, L37335 to "s,". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 308 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 279) [DWC-675] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1709 Line: 37397 Section: regcomp Problem: (regcomp(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P1709, L37397 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 309 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 280) [DWC-676] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1709 Line: 37400 Section: regcomp Problem: (regcomp(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character" on P1709, L37400 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 310 prindle@voicenet.com (rdvk# 302) [prindle.xsh-148] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept the problem, do nothing as covered below in ERN 311, also covered by maths actions elsewhere. _____________________________________________________________________________ Page: 1715 Line: 37612-37615 Section: remainder() Problem: These functions are incorrectly shaded and identified as XSI functionality. Action: Remove shading and XSI margin code from synopsis. Add standard ISO C disclaimer in beginning of description, shaded and marked CX: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. Issues regarding NaN and/or EDOM apply (see [prindle.xsh-25]). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 311 ajosey@opengroup.org Bug in XSHd4 remainder (rdvk# 9) {tog.aug14.9} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove the XSI shading from the complete synopsis block Add to CH The remainder() function is no longer XSI shaded. _____________________________________________________________________________ Page: 1715 Line: 37612 Section: remainder Problem: the remainder family of functions are part of the C standard and should not be XSI shaded Action: Remove the XSI shading from the complete synopsis block Add to CH The remainder() function is no longer XSI shaded. [Ed recommendation: Accept as marked, as above, but add the ISO C disclaimer block, and XSI shade lines 37626,37631] _____________________________________________________________________________ comment Enhancement Request Number 312 prindle@voicenet.com (rdvk# 303) [prindle.xsh-149] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The maths functions are being changed in a global rework to align with ISO C 99. This is a footnote in C99 (footnote 201) and as such non-normative. The WG14 committee has a defect report in progress to confirm this, thus we should exclude this change. _____________________________________________________________________________ Page: 1715 Line: 37620 Section: remainder() Problem: Missing ISO C requirement. Unfortunately, I don't know how to interpret the ISO C requirement, nor it's assertion "This definition is applicable for all implementations", for I do not see how the shall requirement can be met on implementations that do not support signed zero. Is this an error in ISO C? Action: Add to end of paragraph: "If r = 0, its sign shall be that of x." ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 313 ajosey@opengroup.org Bug in XSHd4 (rdvk# 75) {tog.sep4.16} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Overcome by changes elsewhere, see ERN 53 _____________________________________________________________________________ Page: 1719 Line: 37728 Section: remquo Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 37728 and 37733 [Ed recommendation: Accept] _____________________________________________________________________________ Objection Enhancement Request Number 314 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 255) [DST-171] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change 37661 "the application shall ensure that the new argument does" to "the new argument shall" Change 37767 "the application shall ensure that the new argument does" to "the new argument shall" Change 37772 "the application shall ensure that it is an empty directory." to "it shall be required to be an empty directory." Change 37777 "The application shall ensure that the new path name does" to "The new path name shall" _____________________________________________________________________________ Page: 1721 Line: 37767 Section: rename Problem: If a conforming application performs a rename operation, and does not first confirm that the target name does not exist, and the system pulls all the moderator rods from the reactor instead, destroying Philadelphia, is it because the application was not conforming to these words that the fault lies with the application? The current wording states that the application breaks the implied contract if it does not first take the action necessary to assure that the rename function will succeed. Thus, the implementation is in unspecified/undefined space, and can do as it pleases. Action: Restore the old "shall" everywhere that TASA is included, thus avoiding the problem of moving the burden from the implementation to the application where it DOES NOT belong. _____________________________________________________________________________ objection Enhancement Request Number 315 prindle@voicenet.com (rdvk# 304) [prindle.xsh-150] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1723 Line: 37835-37836 Section: rename() Problem: This [ELOOP] error condition is also a CX. Action: Shade and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 316 prindle@voicenet.com (rdvk# 305) [prindle.xsh-151] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1725 Line: 37925-37926 Section: rewind() Problem: This paragraph is a CX. Action: Shade and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 317 ajosey@opengroup.org Bug in XSHd4 (rdvk# 74) {tog.sep4.17} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Overcome by changes elsewhere, see ERN 53 _____________________________________________________________________________ Page: 1729 Line: 38041 Section: rint Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 38041 and 38044 [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 318 ajosey@opengroup.org Bug in XSHd4 (rdvk# 73) {tog.sep4.18} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See ERN 53 _____________________________________________________________________________ Page: 1735 Line: 38210 Section: round Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 38210 and 38213 [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 319 ajosey@opengroup.org Bug in XSHd4 (rdvk# 72) {tog.sep4.19} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See ERN 53 _____________________________________________________________________________ Page: 1737 Line: 38291 Section: scalbln Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 38291 and 38296 [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 320 ajosey@opengroup.org Bug in XSHd4 sched_setparam (rdvk# 34) {tog.aug29.pasc.1.100} Tue, 29 Aug 2000 16:59:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1744 Line: 38491 Section: sched_setparam Problem: IEEE PASC Interpretation #100 has raised an issue for which the sponsor has recommended the following action. Action: Replace 38491-38492 with The target process, whether it is running or not running, shall be moved to the tail of the thread list for its priority. Add to CH IEEE PASC Interpretation 1003.1-96 #100 has been applied. [Ed recommendation: Accept] _____________________________________________________________________________ comment Enhancement Request Number 321 prindle@voicenet.com (rdvk# 306) [prindle.xsh-152] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make the change noted below, note that SCHED_SPORADIC should be shaded SS. _____________________________________________________________________________ Page: 1745 Line: 38516-38518 Section: sched_setparam() Problem: Regarding Note to Reviewers, I see no problem with allowing SCHED_OTHER to utilize the ss parameters. This is consistent with the whole behavior of setting parameters being implementation-defined (line 38521). However, I agree with Donn that the wording is bad. It was fixed on line 38512, and should be here too. Action: Change the last sentence of the previous pagagraph (38513-38515) to: "If the scheduling policy of this process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC, the effects of these members is implementation-defined; this case includes the SCHED_OTHER policy." ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 322 prindle@voicenet.com (rdvk# 307) [prindle.xsh-153] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: There is no action to be applied to the draft _____________________________________________________________________________ Page: 1756 Line: 38844 Section: sem_getvalue() Problem: Deja-vu suggests I've asked this question before, but I guess it was too long ago for me to remember the answer: If this function does not affect the state of the semaphore, why isn't the argument a pointer to a const sem_t? Action: Riddle me that, and if it should be, file an interp against 1003.1-1996 and fix it in the next draft. If this has already been addressed, "never mind". ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 323 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 256) [DST-172] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This text is taken directly from the POSIX.1-1996 description of sem_post(), where it describes specific to this interface which thread shall be unblocked when a thread is blocked on a *semaphore*. This does not appear across a lot of functions or generically for scheduling in the base document. There is wording about scheduling of runnable threads in section 2.8.4 of XSH that provides the information that this change request appears to be attempting to provide. As such we disagree with the problem statement, the wording is clear and since the wording comes from a base document a change is out of scope without an interpretation or resolution. [Notes not part of this response: The position of the group to date regarding placement of this text here backs up the above response: it appears better to have this case of scheduling policy discussion in the sem_post() page, matching the sem_post() description within POSIX. (from an earlier draft review). ] _____________________________________________________________________________ Page: 1762 Line: 34093 Section: sem_post Problem: This belongs in XBD, as it applies across a lot of functions. Action: 1) Delete 35180 starting at "If the Process...." thru to 35188. 2) Replace with "The process to be unblocked is determined according to the process scheduling option. See 4.11. 3) Move the deleted text to 3481 (prior to the discussion of nice also being moved there), preceeding it with "When a process is unblocked," (It's likely that other text needs to be collected there as well, but this is a start.) _____________________________________________________________________________ objection Enhancement Request Number 324 prindle@voicenet.com (rdvk# 292) [prindle.xsh-138] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the action below, but change the "will" to "shall" _____________________________________________________________________________ Page: 1764 Line: 39100 Section: sem_timedwait() Problem: Text from POSIX Std 1003.1d is missing here. Action: Add after the word "function." the following: The resolution of the timeout is the resolution of the clock on which it is based. The timespec datatype is defined as a structure in the C header . Under no circumstance will the function fail with a timeout if the semaphore can be locked immediately. The validity of the abs_timeoutment need not be checked if the semaphore can be locked immediately. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 325 prindle@voicenet.com (rdvk# 376) [prindle.xsh-160] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete lines 40239-40242, 42604-42607 _____________________________________________________________________________ Page: 1801 Line: 40239-40242 Section: setjmp() Problem: See also page 1883 line 42604-42607 section sigsetjmp() This text is left over from longjmp() and does not belong in the description of setjmp(). It is also incomplete, with the complete text appearing incorrectly on the longjmp() page (see [prindle.xsh-102] for that editorial fix to the longjmp() page). Action: Delete these lines. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 326 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 321) [DWC-794] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1805 Line: 40344-40356 Section: setlocale Problem: (setlocale: description) The setting of LC_* and LANG applies to POSIX-conformant systems as well as to XSI-conformant systems. Action: Change "For XSI-conformant system, this" on P1805, L40355-40356 to "This". ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 327 Jon.Hitchcock@uniplex.co.uk Bug in XSHd4 setlocale (rdvk# 226) {jjh7} Fri, 22 Sep 2000 20:01:13 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The requirement is as per the ISO C standard and so this behavior is required for the system interfaces volume as stated. The inconsistency appears to be cross volume in that for the utilities it is specified, we are working on documenting that elsewhere but setlocale() should not change. _____________________________________________________________________________ Page: 1805 Line: 40359 Section: setlocale Problem: Line 40366 suggests that the locale (which is POSIX initially) is unchanged if one of the LC_* variables has an invalid setting. This is contradicted in the other documents. For more explanation see austin-group message 1280, which was not disagreed with. Action: After line 40359 add: Even if some of the variables contain an invalid setting, the locale is changed as specified in these volumes, and the call to setlocale() is considered to have succeeded. Update change history for this change. _____________________________________________________________________________ Comment Enhancement Request Number 328 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 323) [DWC-796] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1806 Line: 40392-40395 Section: setlocale Problem: (setlocale(): rationale) This list doesn't give any indication that LC_MONETARY and LC_MESSAGES are affected by the environment. Action: Add the following after P1806, L40395: 5. Monetary formatting 6. Messaging ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 329 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 322) [DWC-795] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1806 Line: 40393 Section: setlocale Problem: (setlocale(): rationale) String handling includes a lot more than just collating, but it looks like you really do mean collating (as in LC_COLLATE) here. Action: Change "String handling (that is, collating)" on P1806, L40393 to "Collating". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 330 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 324) [DWC-797] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1807 Line: 40421-40422 Section: setlocale Problem: (setlocale(): rationale) There is no requirement that setlocale() return a pointer to a static area. (It is allowed, but not required.) Action: Change "is a pointer to a static area" on P1807, L40421-40422 to "may be a pointer to a static area". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 331 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 325) [DWC-798] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: do as in the action, assuming "setlocal" should be "setlocale" _____________________________________________________________________________ Page: 1807 Line: 40427,40437,40441 Section: setlocale Problem: (setlocale: rationale) The synopses and most of the examples in this draft put a space after the comma separating function arguments. The spaces are missing here. On L40441, it isn't clear whether there is a space between the double quotes. (There should be no space there.) Action: Change "setlocal(category,string)" on P1807, L40427 to "setlocal(category, string)". Change "setlocal(category,"C")" on P1807, L40437 to "setlocal(category, "C")". Change 'setlocal(category," ")' on P1807, L40437 to 'setlocal(category, "")'. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 332 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 326) [DWC-799] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: marked up _____________________________________________________________________________ Page: 1807 Line: 40442-40443 Section: setlocale Problem: (setlocale(): rationale) This is true for XSI-conforming systems too. Action: Change "For POSIX-conforming systems, this" on P1807, L40442-40443 to "This". ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 333 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 327) [DWC-800] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1807 Line: 40447-40449 Section: setlocale Problem: (setlocale(): see also) Some functions are missing from SEE ALSO list Action: Add the following functions to the SEE ALSO list on P1807, L40447-40449: isblank(), isdigit(), isxdigit(), iswblank(), iswdigit(), and iswxdigit(). [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 334 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 328) [DWC-801] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1808 Line: 40460 Section: setlocale Problem: (setlocale(): change history) Missing close paren. Action: Change '(""' on P1808, L40460 to '("")'. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 335 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 329) [DWC-802] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1808 Line: 40465 Section: setlocale Problem: (setlocale(): change history) Missing spaces. Action: Change "char* to const char*" on P1808, L40465 to "char * to const char *". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 336 prindle@voicenet.com (rdvk# 308) [prindle.xsh-154] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1840 Line: 41265 Section: shm_unlink() Problem: Extraneous space between asterisk and "name". Action: Remove the space. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 337 prindle@voicenet.com (rdvk# 309) [prindle.xsh-155] Mon, 25 Sep 2000 20:30:55 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add the new words as suggested below. This reqt was added in the D1 review. XSHd1 ERN 319 Action on AJ to file an interpretation. _____________________________________________________________________________ Page: 1840 Line: 41273-41274 Section: shm_unlink() Problem: I can't find an interpretation on which this additional requirement is based. Also, the requirement is very confusing, and incomplete/incorrect as it stands. However, it is a reasonable change. Action: File an interpretation to formalize this change. Then, I believe it is trying to say: Even if the object continues to exist after the last shm_unlink(), reuse of the name shall subsequently cause shm_open() to behave as if no shared memory object of this name exists (i.e. shm_open() will fail if O_CREAT is not set, or will create a new shared memory object if O_CREAT is set). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 338 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 354) {aj.tog.26sep.23} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1852 Line: 41633 Section: sigaction Problem: shallification Action: change "is defined" to "shall be defined" [Ed recommendation: Accept] _____________________________________________________________________________ objection Enhancement Request Number 339 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 355) {aj.tog.26sep.24} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1852 Line: 41643 Section: sigaction Problem: Missing conforming app reqt from .1-1996 Action: Add after line 41643 "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously". _____________________________________________________________________________ editorial Enhancement Request Number 340 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 356) {aj.tog.26sep.25} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1852 Line: 41652 Section: sigaction Problem: Missing shading Action: "RTS|XSI" shade the sentence starting on line 41652 "If the..." and ending in the middle of 41655 _____________________________________________________________________________ editorial Enhancement Request Number 341 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 353) {aj.tog.26sep.22} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1859 Line: 41928 Section: sigaddset Problem: Need to add additional funcs to the list Action: Add pthread_sigmask(), sigsuspend(), sigtimedwait(), sigwait() and sigwaitinfo() The same change is also need on page 1862 line 42048 and on page 1869 line 42216 _____________________________________________________________________________ editorial Enhancement Request Number 342 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 352) {aj.tog.26sep.21} Wed, 27 Sep 2000 06:16:03 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1863 Line: 42084 Section: sigemptyset Problem: No need to refer to just this volume of.. Action: Change to IEEE Std 1003.1-200x _____________________________________________________________________________ objection Enhancement Request Number 343 prindle@voicenet.com (rdvk# 372) [prindle.xsh-156] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The differences are due to recent changes on the longjmp page requested by the review group. Replace the DESCRIPTION as follows: The siglongjmp( ) function shall be equivalent to the longjmp( ) function, except as follows: bullet item: References to setjmp() shall be equivalent to sigsetjmp() bullet item: text from lines 42265-42266 Add to CH The DESCRIPTION is rewritten in terms of longjmp() _____________________________________________________________________________ Page: 1870 Line: 42253-42264 Section: siglongjmp() Problem: This section attempts (poorly) to duplicate the text in longjmp(), adding the paragraph on restoring the signal mask. In doing so, some descriptive text was omitted, and the requirements for not restoring local auto variables is stated differently (though it may well be equivalent). The omitted text is that which deals with all other components of the abstract machine. It is better to reference the base function than to unsuccessfully duplicate the text here. Action: Adopt the 1003.1-1996 solution and make all this text go away and be replaced by "The siglongjmp() function shall comply with the definition of the longjmp() function in this volume of IEEE Std. 1003.1-200x." Then allow the last two paragraphs to provide the additional context for this function, as in 1003.1-1996. Alternatively, duplicate exactly the text from longjmp(). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 344 prindle@voicenet.com (rdvk# 373) [prindle.xsh-157] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (No change is required for this specific ERN.) Given the reworking of the DESCRIPTION in XSHd4 ERN 343 this text is no longer present. On the longjmp() page the equivalent text is now CX shaded. _____________________________________________________________________________ Page: 1870 Line: 42261-42264 Section: siglongjmp() Problem: I cannot find anywhere in 1003.1-1996 or its amendments where this "more async safe" behavior is specified. As fallout from ISO C 7.1.4 paragraph 4, and without an exception to the contrary for longjmp(), ISO C's longjmp() does not appear to be async safe. 1003.1-1996 does not appear to add this in deriving siglongjmp() from longjmp(). Action: Shade this paragraph and margin code XSI. Or provide an Note to Reviewers requesting that this be made a mandatory change to POSIX semantics. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 345 prindle@voicenet.com (rdvk# 374) [prindle.xsh-158] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The differences in the text relating to "SIGILL or SIGSEGV" are new text in ISO C. The change at 42333 is a glitch. Editorial markup has been passed to the editors to align the sections with the C99 wording. _____________________________________________________________________________ Page: 1872-1873 Line: 42311-42340 Section: signal() Problem: There are just enough minor deviations in the text here from the text in ISO C (including at least the omission of SIGILL and SIGSEGV references, and a glitch near line 42333 which redundantly repeats a requirement) that it would be worthwhile just to replace this entire line range with the text from ISO C suitable re-formatted and with the few reference changes to make it consistent with this document. I won't include all that text here, since copying it twice is twice as likely to get it wrong. Just take it from ISO C. Action: Replace this line range with text from ISO C to avoid the minor differences that have crept in here. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 346 donnte@microsoft.com Bug in XSHd4 Batch 1 (rdvk# 242) [DST-107] Fri, 22 Sep 2000 15:37:00 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This section is being reworded to align with C99 (as per ERN 345), no longer talking of blocking, its not clear whether the problem below exists in the new wording. If so we would suggest a defect report be filed against c99. _____________________________________________________________________________ Page: 1872 Line: 42319 Section: signal Problem: This appears to be a very old problem. This allows the signal to be blocked (rather than being restored to SIG_DFL). It doesn't ever say when it is supposed to be unblocked, that I can find. A conforming implementation could, then, block the signal the first time it occurs, and never unblock it again. In an application using signal, we have to presume it's not signal mask aware, so this turns all signals into potential one-shots. Yes, I'm aware that _longjmp explicitly permits any reasonable behavior, but there's nothing I can find in the standard that allows a programmer to rely on getting more than one of each "synchronous" signal, or to do anything about it if it's otherwise not a signal-mask aware program. (Particularly since the blocking is implementation defined, it might not be something a conforming application can know about.) (Even a program like the old Bourne shell, that relied on retrying failed SIGSEV errors to grow memory, could not work in this sort of environment, because there's no requirement that a NORMAL return from a handler reenable the signal.) (The objective of the change is to allow a portable applicaiton to be written at all... right now it can't be.) Action: At 42320, before "Next...", add. If the signal is blocked, it shall be unblocked when the scope of the handler function is exited, either due to a normal return from the function, having the function do a longjmp() call (but not _longjmp()) to an environment where the signal was not blocked, or other equivalent operations. (I'm not particularly tied to this wording; anything that means "if you take the blocking option, you have to use something like siglongjmp to actually implement longjmp and have to clean up on normal return" is fine.) _____________________________________________________________________________ editorial Enhancement Request Number 347 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 345) {aj.tog.26sep.27} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1878 Line: 42475 Section: sigpending Problem: Shallification Action: Change "function stores" to "function shall store" _____________________________________________________________________________ Objection Enhancement Request Number 348 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 254) [DST-170] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The requirement is from one of the existing base documents and only required for XSI conformance. The Base Working Group disagrees with the proposed action because the restriction documents existing practise, and changing it would decrease concensus. A portable application should not assume that grantpt() will work if it has a signal handler for SIGCHLD [Ed note page # should be 1092] _____________________________________________________________________________ Page: 1902 Line: 19406 Section: grantpt Problem: This a particularly ugly constraint. Action: Remove this sentence. This would require that implementations of grantpt() not require that SIGCHLD not be used. Although I'm not familiar with the details of this function, it seems unnecessary to use SIGCHLD (waitpid() should be enough if it MUST be done as a child process). (Don't standardize brokenness.) _____________________________________________________________________________ objection Enhancement Request Number 349 prindle@voicenet.com (rdvk# 375) [prindle.xsh-159] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Covered by markup in AJ shallification pass _____________________________________________________________________________ Page: 1880 Line: 42519-42522 Section: sigqueue() Problem: Missing shall-ification of this paragraph. Action: Restore missing shalls from 1003.1-1990. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 350 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 348) {aj.tog.26sep.30} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1880 Line: 42519 Section: sigqueue Problem: shallification Action: change "returns immediately" to "shall return immediately" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 351 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 349) {aj.tog.26sep.31} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1880 Line: 42520 Section: sigqueue Problem: shallification Action: change "is queued" to "shall be queued" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 352 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 350) {aj.tog.26sep.32} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1880 Line: 42521 Section: sigqueue Problem: shallification Action: change "is sent at least" to "shall be sent at least" [Ed recommendation: Accept] _____________________________________________________________________________ Editorial Enhancement Request Number 353 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 333) [DWC-806] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1881 Line: 42551,42557 Section: sigqueue Problem: (sigqueue(): rationale) The use of "function" in a couple of places here is awkward. Go back to the POSIX.1-1996 wording. Action: Change "extending the function" on P1881, L42551 to "extending the interface". Change "message queue open in the previous function." on P1881, L42557 to "message queue open in the previous interface.". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ comment Enhancement Request Number 354 prindle@voicenet.com Bug in XSHd4 (rdvk# 46) [prindle.xsh-11] Thu, 31 Aug 2000 14:19:08 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editors are doing a pass of adding ptr pages to the draft (removing them as necessary at the final proof stage) _____________________________________________________________________________ Page: 1883 Line: 42592 Section: sigsetjmp() Problem: A reference page to the sigset() function belongs here alphabetically. It is missing. Action: Add reference page to sigset() located on the signal() page. [Ed recommendation: Accept [add a pointer page]] ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 355 prindle@voicenet.com (rdvk# 377) Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the DESCRIPTION as follows: The sigsetjmp( ) function shall be equivalent to the setjmp( ) function, except as follows: bullet item: References to setjmp() are equivalent to sigsetjmp() bullet item: References to longjmp() are equivalent to siglongjmp() bullet item: text from lines 42606-52603 Add to CH. The DESCRIPTION is reworded in terms of setjmp(). _____________________________________________________________________________ Page: 1883 Line: 42598-42601,42604-42616 Section: sigsetjmp() [prindle.xsh-161] Problem: This section attempts to duplicate the text in setjmp(), adding the paragraph on the additional argument and saving the signal mask. In doing so, some descriptive text was omitted. The omitted text is the requirement after the bulleted list. It is better to reference the base function than to unsuccessfully duplicate the text here. Action: Adopt the 1003.1-1996 solution and make all this text go away and be replaced by "sigsetjmp() shall comply with the definition of setjmp() in this volume of IEEE Std. 1003.1-200x." Then allow the paragraph at 42602-42603 to provide the additional context for this function, as in 1003.1-1996. Alternatively, duplicate exactly the text from setjmp(). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 356 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 346) {aj.tog.26sep.28} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1887 Line: 42726 Section: sigtimedwait Problem: Shallification Action: Change "returns" to "shall return" _____________________________________________________________________________ objection Enhancement Request Number 357 prindle@voicenet.com (rdvk# 378) [prindle.xsh-162] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: marked up _____________________________________________________________________________ Page: 1887 Line: 42734 Section: sigtimedwait() Problem: See also page 1891 line 42873 section sigwait() Missing shall-ification in these lines. Action: Change "is" to "shall be". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 358 ajosey@rdg.opengroup.org BUG in XSHd4 (rdvk# 347) {aj.tog.26sep.29} Wed, 27 Sep 2000 06:59:12 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_357 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1891 Line: 42873 Section: sigwait Problem: shallification Action: change "thread is suspended" to "thread shall be suspended" [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 359 prindle@voicenet.com (rdvk# 391) [prindle.xsh-175] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1894 Line: 42936 Section: sin() Problem: See also page 1994 line 46043 section tan() Singular/plural snafu. Action: Change "its" to "their". [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 360 prindle@voicenet.com (rdvk# 379) [prindle.xsh-163] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept, marked up _____________________________________________________________________________ Page: 1894 Line: 42939 Section: sin() Problem: See also page 1994 line 46046 section tan() See also page 722 line 7615 section cos() [Only second part of action] An interesting qualitative observation, hardly a normative requirement. Action: Move to application usage (as was done for cos()). Include all 3 functions in the statement, not just the "double" one. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 361 prindle@voicenet.com (rdvk# 380) [prindle.xsh-164] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Use wording along the lines of .1-1996, delete "because of premature arousal" _____________________________________________________________________________ Page: 1898 Line: 43058 Section: sleep() Problem: "because of premature arousal"??? Seriously, did we have a reason for adding these words. Perhaps to make sleep() seem less boring? Action: Somehow, I think it was better without this addition. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 362 prindle@voicenet.com (rdvk# 381) [prindle.xsh-165] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: Refer to Andrew Gollan _____________________________________________________________________________ Page: 1901 Line: 43138-43139 Section: socket() Problem: See also page 1903 line 43209-43210 section socketpair() This statement (that all socket types are implementation-defined) is incorrect. Normative requirements in XSH at line 2589-2591, and in XBD at line 13045-13048 require at least the 3 socket types below. Action: Change "The socket types... include:" to "The following socket types are defined; Implementations may specify additional socket types:" ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 363 prindle@voicenet.com (rdvk# 382) [prindle.xsh-166] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: refer to Andrew Gollan _____________________________________________________________________________ Page: 1901 Line: 43151 Section: socket() Problem: See also page 1903 line 43221 section socketpair() The first sentence of the paragraph explains what happens if protocol is non- zero. Text to explain what happens if protcol is zero is missing. Action: Add after first sentence: If the protocol argument is zero, the default protocol for this address family and type shall be used. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 364 Don.Cragun@eng.sun.com BUG in XSHd4 (rdvk# 17) [DWC-Alt-1] Fri, 18 Aug 2000 12:46:52 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1914 Line: 43447 Section: stat() Problem: I have seen the ballot comment from Andries Brouwer saying: "An off_t is printed with a %9ld format, but it may be larger than what fits into a long." I agree with his concern, but disagree with his proposed action. The example that contains this printf() prints several fields. This is the only only one that doesn't have an explicit space to separate the output from the previous field where the results would cause an ambiguity. Therefore, even going from ``%9ld'' to ``"%12" PRIdMAX'' doesn't guarantee that a group name from the previous printf() won't run into the size field from this printf(). Furthermore, the definition of PRIdMAX doesn't appear in any of the headers currently listed in this example. (It appears in .) And, intmax_t isn't defined in any of the headers in this example either. (It appears in .) And, examples using printf() should include . Some e-mail discussions on this topic have suggested using the ``j'' length modifier with the ``d'' conversion specifier instead of ``PRIdMAX'', but they have still missed the need for a leading space in the format and for inclusion of . Also note that the file systems I most often work with now can have a sparse files with sizes well over 999,999,999,999 bytes in length. Adding a leading space to the format removes any ambiguity that might be caused by filling the field width without reserving extra space in the output for the small number of files that have sizes larger than 999,999,999 bytes. Using 12 instead of 9 doesn't solve this problem by itself. Action: Add after P1913, L43420: #include #include Change P1914, L43447 from: printf("%9ld", statbuf.st_size); to: printf(" %9jd", (intmax_t)statbuf.st_size); [Ed note: statbuf.st_gid was corrected to statbuf.st_size in the code above] _____________________________________________________________________________ Comment Enhancement Request Number 365 Andries.Brouwer@cwi.nl BUG in XSHd4 (rdvk# 16) [] Thu, 17 Aug 2000 07:20:06 +0200 (MET DST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_364 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1914 Line: 43447 Section: stat() Problem: An off_t is printed with a %9ld format, but it may be larger than what fits into a long. Action: Replace this line by printf("%12" PRIdMAX, (intmax_t) statbuf.st_size); _____________________________________________________________________________ objection Enhancement Request Number 366 prindle@voicenet.com (rdvk# 384) [prindle.xsh-168] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1917 Line: 43548 Section: stdin Problem: This line is not an ISO C requirement. Action: Shade this line and mark CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 367 prindle@voicenet.com Bug in XSHd4 (rdvk# 161) [prindle.xsh-73] Tue, 19 Sep 2000 07:55:54 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (see editorial markup) Add Stdc disclaimer block Add "Typically... " as noted below to the end of the first sentence. CX shade references to perror() and LC_MESSAGES, and need not be reentrant, and setting/checking setting of errno Mark references to strerror_r as TSF Add to the CH , The strerror_r() function is marked as a part of the THREAD_SAFE_FUNCTIONS option. _____________________________________________________________________________ Page: 1930 Line: 43961-43985 Section: strerror() Problem: The ISO C function strerror() is not appropriately flagged as such, nor are departures from ISO C shaded and marked CX. Action: Add before line 43961 the following paragraph: "The functionality of strerror() 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." [ISO C contains two requirements that are different from what we have here (not simply an extension): a) the string returned is not allowed to be overwritten by a subsequent call to perror(). b) a string shall be returned for any value of errnum. I don't see how we can "extend" those requirements away...] SO..... On line 43963, delete "or perror()". On line 43962, add after "pointer to it." the following: Typically, the values for errnum come from errno, but strerror shall map any value of type int to a message. Delete lines 43968-43970. Replace lines 43976-43977 with "The function strerror() shall return a pointer to the generated message string." Delete lines 43981-43982. Shade and mark with margin code CX: All of lines 43964-43965 The phrase "defined in this volume...200x" on lines 43966-43967 All of lines 43971-43972 The sentence "On error...an error." on lines 43976-43977 ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 368 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 283) [DWC-679] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1932 Line: 44047 Section: strfmon Problem: (strfmon(): character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P1932, L44047 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 369 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 284) [DWC-680] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1932 Line: 44048 Section: strfmon Problem: (strfmon(): character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " character." on P1932, L44048 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 370 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 285) [DWC-681] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1933 Line: 44077 Section: strfmon Problem: (strfmon(): character) The term is defined (XBD6d4, P101, L2843-2846) to be a synonym for "space character". Therefore, the phrase " character" expands to "space character character". Action: Change " characters" on P1933, L44077 to "s". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 371 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 281) [DWC-677] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1937 Line: 44203 Section: strftime Problem: (strftime(): character) The term is defined (XBD6d4, P82, L2390-2394) to be a synonym for "newline character". Therefore, the phrase " character" expands to "newline character character". Action: Change " character." on P1937, L44203 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 372 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 286) [DWC-682] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1937 Line: 44209 Section: strftime Problem: (strftime(): character) The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for "tab character". Therefore, the phrase " character" expands to "tab character character". Action: Change " character." on P1937, L44209 to ".". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ editorial Enhancement Request Number 373 prindle@voicenet.com (rdvk# 386) [prindle.xsh-170] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1957 Line: 44866 Section: strtod() Problem: Too much text is shaded. Action: Remove shading on all except "or POSIX". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 374 prindle@voicenet.com (rdvk# 387) [prindle.xsh-171] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "The xxx() function" to "These functions" on line 45144, 45146 also on p 1968 l 45241 and 45244 p 1957 l 44884 and 44886 _____________________________________________________________________________ Page: 1965 Line: 45144,45146 Section: strtol() Problem: See also page 1968 line 45241,45244 section strtoul() The strtoll() and strtoull() functions can't fail? Action: Include both functions in the shall fail/may fail text. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 375 prindle@voicenet.com (rdvk# 388) [prindle.xsh-172] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The XSI extensions over ISO C for strtol() and strtoul() have been defined for sometime. It is out of scope to change these arbritrarily without an interpretation or resolution. To do so may decrease consensus. _____________________________________________________________________________ Page: 1965 Line: 45144 Section: strtol() Problem: If strtoul() can fail if base is not between 2 an 36, so should strtol(). Action: Add shaded and coded CX: [EINVAL] The value of base is not supported. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 376 prindle@voicenet.com (rdvk# 389) [prindle.xsh-173] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If command is a null pointer, the system() function determines whether the host environment has a command processor. If command is not a null pointer, the system() function passes the string pointed to by command to that command processor to be executed in an implementation-defined manner; this might then cause the program calling system() to behave in a non-conforming manner or to terminate. (note the contents of the second sentence were already in the second paragraph) _____________________________________________________________________________ Page: 1989 Line: 45840-45843 Section: system() Problem: The first sentence is an incomplete description of ISO C system() functionality. The second sentence is a CX. Action: Replace the first sentence by: If command is a null pointer, the system() function determines whether the host environment has a command processor. If command is not a null pointer, the system() function passes the string pointed to by command to that command processor to be executed in an implementation-defined manner; this might then cause the program calling system() to behave in a non-conforming manner or to terminate. Shade the second sentence and margin code it CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 377 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 257) [DST-173] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept, Marked up on the draft _____________________________________________________________________________ Page: 1991 Line: 45922 Section: system Problem: The sentence "in its base definition" is nonsense. This standard says PRECISELY how system is to work because defines both parts. This is a leftover from the days when .1 and .2 were separate. Note in particular the very next sentence/paragraph that contradicts this. Action: Delete sentence. _____________________________________________________________________________ comment Enhancement Request Number 378 prindle@voicenet.com (rdvk# 390) [prindle.xsh-174] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1993 Line: 46029 Section: system() Problem: I doubt the .1a alignment happened in Issue 4, since .1a was integrated only recently. Action: Add header showing where Issue 6 changes start. [Ed recommendation:Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 379 prindle@voicenet.com (rdvk# 392) [prindle.xsh-176] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1996 Line: 46102 Section: tanh() Problem: Spelling error. Action: Replace "ompute" with "compute". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 380 prindle@voicenet.com (rdvk# 393) [prindle.xsh-177] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Editors do the right thing. _____________________________________________________________________________ Page: 2009 Line: 46461 Section: tcsendbreak() Problem: Shouldn't the ISO designation for decimal fractions be used? It was in 1003.1- 1996. I'm no expert, maybe the rules have changed. Action: Replace 0.25 by 0,25. Replace 0.5 by 0,5. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 381 ajosey@opengroup.org Bug in XSHd4 (rdvk# 71) {tog.sep4.20} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See 53 _____________________________________________________________________________ Page: 2024 Line: 46942 Section: tgamma Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 46942 and 46952 [Ed recommendation: Accept] _____________________________________________________________________________ Objection Enhancement Request Number 382 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 330) [DWC-803] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2024 Line: 46949 Section: tgamma Problem: (tgamma():return value vs. errors) The return values section says you should get an EDOM error if x is a negative integer; the errors section says you should get an EDOM error if x is negative. With double, float, and long double arguments; these don't mean the same thing. Action: Change "The value of x is negative" on P2024, L46949 to "The value of x is a negative integer". ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 383 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 258) [DST-174] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2032 Line: 47226 Section: timer_getoverrun Problem: spelling Action: shal -> shall. _____________________________________________________________________________ Objection Enhancement Request Number 384 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 259) [DST-175] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change to "with" _____________________________________________________________________________ Page: 2032 Line: 47231 Section: timer_getoverrun Problem: I don't know what "on pending expration" means. Pending means "hasn't happened yet", and "on" (usually, in this context) means "when something occurs" , so this says "when something that hasn't yet occurred has (already) occurred". I suspect the right word is "with", but it's unclear. Action: Change to "with" or "which has", or otherwise clarify. _____________________________________________________________________________ editorial Enhancement Request Number 385 Jon.Hitchcock@uniplex.co.uk Bug in XSHd4 tmpfile (rdvk# 310) {jjh13} Mon, 25 Sep 2000 20:19:15 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2039 Line: 47413-47414 Section: tmpfile Problem: Lines 47413-47414 ("The largest value that can be represented correctly in an object of type off_t is established as the offset maximum in the open file description") will cause unneccesary worry to application writers thinking of using tmpfile(). These words appear at lines 12587-12588 in the description of fopen(), and the descrition of tmpfile() says "The file is opened as in fopen() for update (w+)." Action: Remove lines 47413-47414 and lines 47467-47468 (change history). _____________________________________________________________________________ objection Enhancement Request Number 386 ajosey@opengroup.org Bug in XSHd4 (rdvk# 91) {tog.sep4.21} Mon, 4 Sep 2000 11:29:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN 53 _____________________________________________________________________________ Page: 2049 Line: 47772 Section: trunc Problem: The NaN handling on these two lines should be XSI shaded to be consistent with other XSI extensions to the maths functions Action: XSI shade line 47772 and 47775 [Ed recommendation: Accept] _____________________________________________________________________________ Objection Enhancement Request Number 387 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 260) [DST-176] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The description says its unspecified for other functions besides exec or _exit(), i.e. portable applications should only call those functions. This function is for compatibility only and documents existing practise (the text of much of the interface also appears in the BSD Programmers manual). The wording as is, is from a Base document, and encompasses the many implementations, to change it would decrease consensus. However we can agree to make this interface obsolescent to discourage its use by portable applications. Mark the SYNOPIS OB (obsolescent) Add at the start of APPLICATION USAGE Portable applications are recommended not to depend on vfork() but to use fork() instead. The vfork() function may be withdrawn in the future. Add to FUTURE DIRECTIONS. This interface may be withdrawn in the future. _____________________________________________________________________________ Page: 2086 Line: 28792 Section: vfork Problem: I'll try ONE MORE TIME to emphasize the extreme brokenness of the current wording. If this doesn't work, I'll give up and simply observe to anyone that asks that the XSI vfork is utterly useless for any practical purpose, and in particular cannot be used to implement spawn(). The current text says that the child shall call NO OTHER FUNCTION but exec*() or _exit(). In particular, that includes dup/dup2/fcntl, so file descriptors cannot be reassigned. In particular, that includes close() so that file descriptors cannot be closed. Thus it is not possible to rearrange the file descriptors between vfork() and exec(). Action: Choose one: - Delete vfork as unsaveable. - Enumerate the list of system provided functions that may be called. The list from the original development of spawn() (which I don't have handy) is a good candidate. As a start, add at 48795: In addition, the following functions may be called in the child: dup(), dup2(), fcntl(..., F_DUPFD...) and close(). _____________________________________________________________________________ editorial Enhancement Request Number 388 prindle@voicenet.com (rdvk# 394) [prindle.xsh-178] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2078 Line: 48558,48593 Section: usleep() Problem: ISO number punctuation problem (2 places). Action: Avoid the problem, spell out "one million". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 389 ajosey@opengroup.org Bug in XSHd4 vsnprintf (rdvk# 11) {tog.aug14.10} Mon, 14 Aug 2000 13:38:31 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2088 Line: 48846 Section: vsnprintf Problem: vsnprintf(and snprintf) are now in the C Standard and should not be XSI shaded on this man page (vprintf). Action: Remove the XSI shading on lines: 48846,48854,48885 Delete "For vfprintf()... :" on 48850 [Ed recommendation: Accept] _____________________________________________________________________________ editorial Enhancement Request Number 390 prindle@voicenet.com (rdvk# 395) [prindle.xsh-179] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2093 Line: 49008-49009 Section: vprintf() Problem: See also page 2094 line 49018-49019 section vscanf() See also page 2095 line 49030 section vswprintf() These functions need a separate pointer page because another function name lies in between them and the first function on the page. Action: Move these to a separate pointer page. [Ed recommendation: Accept] ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 391 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 263) [DWC-659] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2112 Line: 49562 Section: wcscoll Problem: (wcscoll(): can't tell if error was found) The draft is correct in noting that C99 doesn't require that wcscoll() detect any errors or require that errno be set. It is also correct to allow implementations to skip checking for the error listed in the Errors section, but if an error is detected we should require that errno be set. Action: Change "On error, wcscoll() may set errno," on P2112, L49652 to "On error, wcscoll() shall set errno,". ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 392 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 264) [DWC-660] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2112 Line: 49566-49567 Section: wcscoll Problem: (wcscoll(): unmarked extension to C99) The C99 standard does not mention setting errno to EINVAL for this error. Action: Shade and CX mark P2112, L49566-49567. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 393 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 335) [DWC-808] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2128 Line: 50068-50070,50073 Section: wcstod Problem: (wcstod(): description) Setting errno to EINVAL in this case is an extension to C99. Action: Shade "and errno may be set to [EINVAL]." on P2128, L50073 using margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 394 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 334) [DWC-807] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2128 Line: 50068-50070,50073 Section: wcstod Problem: (wcstod(): description) These lines are an extension to C99. The suggestion to set errno to zero, call the function, and then check errno applies to wcstold() as well as to wcstod(). Action: Shade P2128, L50068-50070 using margin code CX. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 395 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 336) [DWC-809] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2128 Line: 50074 Section: wcstod Problem: (wcstod(): return value) A phrase from C99 was dropped that changes required behavior of wcstod(). Action: Change "If the correct value is outside the range of representable values, HUGE_VAL, HUGE_VALF," on P2128, L50074 to "If the correct value is outside the range of representable values, plus or minus HUGE_VAL, HUGE_VALF,". ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 396 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 337) [DWC-810] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2129 Line: 50120 Section: wcstod Problem: (wcstod(): change history) The Issue 6 change history on P2129, L50121-50122 says the return value section has been updated extensively. Although this is true, since the return value for the underflow case is incompatible with C89, POSIX.1-1996, and SUSv2; the difference shoould be explained more fully. Action: Add a new bullet to the list after P2129, L50120: If the correct value for wcstod() would cause underflow, the return value changed from 0 (as specified in Issue 5) to the smallest normalized positive number. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 397 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 338) [DWC-811] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2134 Line: 50269-50272 Section: wcstol Problem: (wcstol(): description) The text on P2134, L50269-50272 is an extension to C99 and applies to both wcstol() and wcstoll(). Action: Change "The wcstol() function" on P2134, L50269 to "These functions". Change "then call wcstol()," on P2134, L50277 to "then call wcstol() or wcstoll(),". Shade P2134, L50269-50272 using the CX margin code. [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 398 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 339) [DWC-812] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2134 Line: 50276 Section: wcstol Problem: (wcstol(): return value) Some words from C99 were lost when the wcstol() and wcstoll() pages were merged. Action: Change "{LONG_MAX} or {LONG_MIN}" on P2134, L50276 to "{LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX}". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 399 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 340) [DWC-813] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2138 Line: 50360,50362 Section: wcstoul Problem: (wcstoul(): synopsis) The function return types for wcstoul() and wcstoull() don't match the function prototypes in on P463. The function prototypes in are correct. Action: Change "long wcstoul" on P2138, L50360 to "unsigned long wcstoul". Change "long long wcstoull" on P2138, L50362 to "unsigned long long wcstoull". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Editorial Enhancement Request Number 400 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 341) [DWC-814] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2138 Line: 50368,50369 Section: wcstoul Problem: (wcstoul(): description) It looks like some text was copied from a place that talked about wcstol(), wcstoll(), wcstoul(), and wcstoull() onto this page that only talks about the last two functions. When using "respectively" in the description, we need an explicit list of the functions; not just "these functions". Action: Change "These functions shall convert" on P2148, L50368 to "The wcstoul() and wcstoull() functions shall convert". Change "long, long long, unsigned long, and unsigned long long" on P2138, L50369 to "unsigned long, and unsigned long long". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 401 Don.Cragun@eng.sun.com Bug in XSH6d4 (rdvk# 342) [DWC-815] Tue, 26 Sep 2000 23:49:18 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2139 Line: 50411,50413 Section: wcstoul Problem: (wcstoul(): return value) The "these functions" on L50411 refers to wcstoul() and wcstoull(), but the {ULONG_MAX} later in this sentence only applies to wcstoul(). Action: Change "these functions" on P2139, L50411 to "wcstoul() and wcstoull()". Change "{ULONG_MAX}" on P2139, L50413 to "{ULONG_MAX} or "{ULLONG_MAX}, respectively,". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 402 prindle@voicenet.com (rdvk# 396) Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2143 Line: 50532-50533,50538-50539 Section: wcsxfrm() [prindle.xsh-180] Problem: These lines are CX. Action: Shade and margin code CX. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 403 donnte@microsoft.com Bug in XSHd4 Batch 2 (rdvk# 261) [DST-177] Fri, 22 Sep 2000 15:37:17 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "(because they begin a comment)" to "(because they begin or continue a comment) _____________________________________________________________________________ Page: 2157 Line: 50976 Section: wordexp Problem: (We'll try again.) This is truth in advertising: the current phrasing allows the implementation to do either of two (mutually exclusive) things. It is incumbent upon the application to assure that it will do what the application expects. Action: Add "The application shall assure that every member of _words_ which it expects to have expanded by wordexp() does not contain an unquoted initial comment character. The application shall also assure that any words which it intends to be ignored (because they begin a comment) are deleted from _words_." This is because if an application expects that # begins a comment, and the implementation expands things past the comment, the application will get junk. Conversely, if the application DOES expect unquoted # comments to be expanded, the implementation doesn't have to. Thus the application has to deal with that problem too. (In the latter case: consider an application developed on a system that DID honor #comment as a comment; it takes input lines, breaks them up a little, and passes them to wordexp relying on parsing to stop on the first comment character. Consider the effects of porting this application to a system that does not honor the #comment rule, and giving this as an input line: foo bar # we would never write $(rm\ -rf\ /) would we? Frankly, I'd prefer that ONE of the two choices be made, but if not at least make it clear to the application writer that he has to deal with the problem of comments. _____________________________________________________________________________ Editorial Enhancement Request Number 404 Don.Cragun@eng.sun.com Bug in XSHd4 (various) (rdvk# 267) [DWC-663] Mon, 25 Sep 2000 09:29:40 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2159 Line: 51086 Section: wordexp Problem: (wordexp(): character) The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for "blank character". Therefore, the phrase " character" expands to "blank character character". Action: Change " character" on P2159, L51086 to "". [Ed recommendation: Accept] ------------------------------------------------------------------------------ _____________________________________________________________________________ objection Enhancement Request Number 405 gwc@unisoft.com BUG in XSHd4 write (rdvk# 262) {gwc write SIGXFSZ} Mon, 25 Sep 2000 11:40:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2163 Line: 51177-51180 Section: write Problem: The text relating to SIGXFSZ is badly out of place and misleading. It is tacked on to the end of some text beginning "For example", which is there to illustrate how a short write occurs, rather than an error, when there is room for some of the data. A selected history of the relevant paragraph shows how the problem arose. POSIX.1-1990 had the following: "If a write() requests that more bytes be written than there is room for (for example, the physical end of a medium), only as many bytes as there is room for shall be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a nonzero number of bytes would give a failure return (except as noted below)." This text clearly applies to limits for which the failure return would be ENOSPC as well as those for which it would be EFBIG. Notice also the different uses of "shall", "will" and "would". XSH4 changed it slightly, adding a reference to ulimit ("for example, the ulimit or the physical end of a medium") and changing both the "shall" and the "would" to "will". It was in the change to XSH4.2 that the badly-placed text relating to SIGXFSZ was added: "and the implementation will generate a SIGXFSZ signal for the process." XSH5 has the same as XSH4.2 but with "process" changed to "thread". The POSIX.1-1996 text is the same as POSIX.1-1990. The current XSHd4 text has been taken from XSH5, with "ulimit" changed to "file size limit", and *all* the occurrences of "will" changed to "shall" (including the ones that are not "shall" in POSIX.1-1996). The badly placed SIGXFSZ text, in combination with the various changes of would/will to shall, mean that the current text is highly misleading. It implies that SIGXFSZ is generated under conditions for which it certainly should not be generated, such as on an ENOSPC error. The best solution would be to change the text beginning "For example" and ending at the end of the paragraph back to how it was in POSIX.1-1996, and to add some alternative text relating to SIGXFSZ. Since the behaviour when extending a file using a particular file descriptor should be the same regardless of whether write() or ftruncate() is used, the new text should be consistent with the relevant text in the description of ftruncate(). It seems clear to me from the text relating to SIGXFSZ and SIGXCPU on the ftruncate/truncate, getrlimit/setrlimit and signal.h pages, that the original intention was for SIGXFSZ to relate explicitly to RLIMIT_FSIZE, the same as SIGXCPU does to RLIMIT_CPU. The actions described below are based on that assumption. If the group feels there is a need to allow SIGXFSZ to be generated when other kinds of size limit are exceeded, such as the maximum file size identified by FILESIZEBITS, then a slightly different action to that given below will be needed, including changes to the ftruncate/truncate page, and possibly the signal.h page as well. Action: On line 51178 change "shall return 20" to "will return 20" and change "shall give a failure" to "would give a failure". On line 51179 delete the XSI-shaded text: "and the implementation shall generate a SIGXFSZ signal for the thread". After line 51180 add a new XSI-shaded paragraph, copied from the ftruncate description (page 958 line 15215) - after aardvark {gwc ftruncate 1} has been applied (which changes the last word from "process" to "thread"): "If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the thread." _____________________________________________________________________________ editorial Enhancement Request Number 406 prindle@voicenet.com (rdvk# 397) [prindle.xsh-181] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2163 Line: 51181 Section: write() Problem: Spelling error. Action: Change "eturn" to "return". ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 407 prindle@voicenet.com (rdvk# 398) [prindle.xsh-182] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add --- SHM XSI If fildes refers to a shared memory type, the result of the writev() or pwrite() functions is unspecified. TYM XSI If fildes refers to a typed memory type, the result of the writev() or pwrite() functions is unspecified. Similarly on p 1681, changing writev()-> readv() and pwrite() -> pread() _____________________________________________________________________________ Page: 2165 Line: 51262-51264 Section: write() Problem: See also page 1681 line 36422-36423 section read() These statements are incomplete due to the addition of XSI functions. Action: Add additional lines like these, but margin coded with XSI in addition to the codes already here, and list the XSI functions as also having unspecified results if fildes refers to these certain file types. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 408 prindle@voicenet.com (rdvk# 399) [prindle.xsh-183] Tue, 26 Sep 2000 21:27:00 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2166 Line: 51298 Section: write() Problem: This error, and all those that mention "connection-mode" socket in both write() and read() should refer to a socket in general, regardless of whether it is connection-mode or connectionless. This is because, it turns out, this specification of sockets allows connect() to be used to prespecify the destination address/port for a connectionless socket, and then read() and write() still are allowed. Action: Here, and in all of write() errors, and in all of read() errors, delete the adjective "connection-mode" modifying the noun "socket". If this is accepted, [prindle.xsh-147] is OBE. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 409 Jon.Hitchcock@uniplex.co.uk Bug in XSHd4 (rdvk# 225) {jjh10} Fri, 22 Sep 2000 20:33:47 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_327 Reject_____ Rationale for rejected or partial changes: Also note that the first change proposed is a dup of the change in XSHd4 ERN 326. _____________________________________________________________________________ Page: 3359 Line: 40355 Section: Internationalization Problem: Lines 40355-40357 say "For XSI-conformant systems, this corresponds to the value of the associated environment variables, LC_* and LANG;" Line 40442 says that "For POSIX-conforming systems, this corresponds to the value of the environment variables." Chapter 8.2 of XBDd4 does not say that anything about these variables is specific to XSI or non-XSI systems. Action: At line 40355 delete the words "For XSI-conformant systems," Get someone who knows the history to revise the rationale. Note that most of this is not actual rationale; it just repeats the "Description".