Document Number: AUSTIN/62r2
Title: XSHd4 Aardvark Change Request Report (FINAL)
Revision Date: 2000-12-14
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 Accept as marked
ERN 363 Accept
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
#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_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change the paragraph at both locations to read:
The type argument specifies the socket type, which determines the semantics
of communications over the socket. The system shall support SOCK_DGRAM
and SOCK_STREAM, and may support other types.
The semantics of the types are:
_____________________________________________________________________________
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_X___ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
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".