Document Number: AUSTIN/49r1 Title: XBDd3 Aardvark Change Request Report Revision Date: 2000-07-27 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XBD Draft 3. Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Accept as marked ERN 3 Accept as marked ERN 4 Accept as marked ERN 5 Accept as marked ERN 6 Reject ERN 7 Reject ERN 8 Accept ERN 9 Accept as marked ERN 10 Accept as marked ERN 11 Accept ERN 12 Accept as marked ERN 13 Accept ERN 14 Accept as marked ERN 15 Accept ERN 16 Accept ERN 17 Accept as marked ERN 18 Accept ERN 19 Accept as marked ERN 20 Accept as marked ERN 21 Accept as marked ERN 22 Accept as marked ERN 23 Accept ERN 24 Accept as marked ERN 25 Accept as marked ERN 26 Reject ERN 27 Accept as marked ERN 28 Reject ERN 29 Reject ERN 30 Accept ERN 31 Accept as marked ERN 32 Accept as marked ERN 33 Accept as marked ERN 34 Reject ERN 35 Accept as marked ERN 36 Accept as marked ERN 37 Accept as marked ERN 38 Reject ERN 39 Reject ERN 40 Accept as marked ERN 41 Accept as marked ERN 42 Duplicate of 41 ERN 43 Duplicate of 37 ERN 44 Accept ERN 45 Accept as marked ERN 46 Accept as marked ERN 47 Duplicate of 46 ERN 48 Accept as marked ERN 49 Duplicate of 48 ERN 50 Duplicate of 48 ERN 51 Accept as marked ERN 52 Accept as marked ERN 53 Accept as marked ERN 54 Accept as marked ERN 55 Reject ERN 56 Accept as marked ERN 57 Reject ERN 58 Accept as marked ERN 59 Accept as marked ERN 60 Accept as marked ERN 61 Duplicate of 60 ERN 62 Accept as marked ERN 63 Accept as marked ERN 64 Accept as marked ERN 65 Accept ERN 66 Duplicate of 25 ERN 67 Duplicate of 37 ERN 68 Accept as marked ERN 69 Duplicate of 37 ERN 70 Accept ERN 71 Accept as marked ERN 72 Accept as marked ERN 73 Duplicate of 72 ERN 74 Accept as marked ERN 75 Accept as marked ERN 76 Duplicate of 48 ERN 77 Accept ERN 78 Accept as marked ERN 79 Accept ERN 80 Accept ERN 81 Accept as marked ERN 82 Reject ERN 83 Reject ERN 84 Reject ERN 85 Reject ERN 86 Accept ERN 87 Accept as marked ERN 88 Accept ERN 89 Accept ERN 90 Reject ERN 91 Accept as marked ERN 92 Accept ERN 93 Accept ERN 94 Duplicate of 93 ERN 95 Accept as marked ERN 96 Accept as marked ERN 97 Reject ERN 98 Reject ERN 99 Reject ERN 100 Accept ERN 101 Reject ERN 102 Accept ERN 103 Accept ERN 104 Reject ERN 105 Accept ERN 106 Reject ERN 107 Reject ERN 108 Reject ERN 109 Reject ERN 110 Reject ERN 111 Accept as marked ERN 112 Reject ERN 113 Accept ERN 114 Accept as marked ERN 115 Accept as marked ERN 116 Accept as marked ERN 117 Accept ERN 118 Accept ERN 119 Reject ERN 120 Reject ERN 121 Reject ERN 122 Accept ERN 123 Accept ERN 124 Accept as marked ERN 125 Accept ERN 126 Accept ERN 127 Reject ERN 128 Accept ERN 129 Accept as marked ERN 130 Accept ERN 131 Accept as marked ERN 132 Accept ERN 133 Accept ERN 134 Accept as marked ERN 135 Accept ERN 136 Accept ERN 137 Accept ERN 138 Accept ERN 139 Accept ERN 140 Accept ERN 141 Accept as marked ERN 142 Accept ERN 143 Accept ERN 144 Accept as marked ERN 145 Accept ERN 146 Accept ERN 147 Accept as marked ERN 148 Accept as marked ERN 149 Accept ERN 150 Accept as marked ERN 151 Accept ERN 152 Accept ERN 153 Accept ERN 154 Accept as marked ERN 155 Accept ERN 156 Accept ERN 157 Accept ERN 158 Accept ERN 159 Accept ERN 160 Accept ERN 161 Accept ERN 162 Accept ERN 163 Accept as marked ERN 164 Accept as marked ERN 165 Reject ERN 166 Accept ERN 167 Accept ERN 168 Accept ERN 169 Accept ERN 170 Accept ERN 171 Accept ERN 172 Accept ERN 173 Accept ERN 174 Accept ERN 175 Accept ERN 176 Accept ERN 177 Accept ERN 178 Accept as marked ERN 179 Accept as marked ERN 180 Accept ERN 181 Duplicate of 180 ERN 182 Reject ERN 183 Accept ERN 184 Accept as marked ERN 185 Accept as marked ERN 186 Accept as marked ERN 187 Accept ERN 188 Accept ERN 189 Accept ERN 190 Accept ERN 191 Accept ERN 192 Accept ERN 193 Accept ERN 194 Accept ERN 195 Reject ERN 196 Accept ERN 197 Accept ERN 198 Accept ERN 199 Accept ERN 200 Accept ERN 201 Accept ERN 202 Accept as marked ERN 203 Accept as marked ERN 204 Accept ERN 205 Accept ERN 206 Accept ERN 207 Reject ERN 208 Accept ERN 209 Accept ERN 210 Accept ERN 211 Accept ERN 212 Accept ERN 213 Accept ERN 214 Accept ERN 215 Accept as marked ERN 216 Accept ERN 217 Accept ERN 218 Accept ERN 219 Accept ERN 220 Accept ERN 221 Accept ERN 222 Accept ERN 223 Accept as marked ERN 224 Accept ERN 225 Accept ERN 226 Duplicate of 227 ERN 227 Accept ERN 228 Accept ERN 229 Accept as marked ERN 230 Accept ERN 231 Accept ERN 232 Accept _____________________________________________________________________________ editorial Enhancement Request Number 1 drepper@redhat.com Bug in XBDd3 (rdvk# 7) {ud-8} Sun, 26 Mar 2000 00:25:15 GMT _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: we should be uniform; use the shortest unambiguous type specifer (e.g. "long", not "long int"). _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: The standard text is inconsistent on how to write types. In many places we find long var; others feature long int var; The same is true for unsigned int and unsigned long int. While I prefer the second method (always spelling out the full type name) I don't care much about what regulation is followed. But there should be one(!) spelling. I filed this for XBD but it is true for the other parts as well. Action: Change in all code fragments unsigned to unsigned int long to long int unsigned long to unsigned long int or the other way around. _____________________________________________________________________________ objection Enhancement Request Number 2 ajosey@opengroup.org Bug in XBDd3 (rdvk# 95) {integral-vs-integer-types} Sun, 30 Apr 2000 09:01:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use "integer type" from c99. Remove the definition of "Extended Integral Type" on p58. This is in all three (or four) books. "integral type" -> "integer type", "extended signed integral type" -> "signed integer type" (similarly for unsigned) _____________________________________________________________________________ Page: 0 Line: 0 Section: global Problem: Historically the Base specifications have used the term "extended integral type" to allow them to have extended integer types beyond the C standard. Now with c99 , the C standard has caught up, however the C standard uses different terminology ie. "integer type". We need to align the specs with the c99 terminology. Action: The group needs to check case-by-case places in the spec. This may be worthy of a separate agenda item page 58 l 1012 page 58 l 1021 page 89 l 2573 page 232 l 7731 page 277 l 9110 (plus many others on p277) page 297 l 9935 page 311 l 10355 page 312 l 10419 page 316 l 10542 page 334 l 11102 page 345 l 11546 (plus others on this page) page 370 l 12366 page 376 l 12532/12534 page 393 l 13125 (plus others on this page) page 404 l 13463 page 438 l 14740 _____________________________________________________________________________ Comment Enhancement Request Number 3 donnte@microsoft.com Bug in XBDd3 (rdvk# 97) [DT-XBD-1] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: everyone worked hard, and was tired and cranky on completion. Apologies accepted. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: I'm tired and cranky after having read the whole document, and (unhappily) having found far more than I wanted to. Action: Please accept my apologies in advance for testy tone. _____________________________________________________________________________ Comment Enhancement Request Number 4 donnte@microsoft.com Bug in XBDd3 (rdvk# 98) [DT-XBD-2] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: although this was attempted, it is possible that sometimes some of these words have either been missed or repeated. Since D4 will be feature complete, and all words should be there, please submit explicit aadvark comments on this next draft on each case where sections have been omitted or repeated. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: The reorgainzation from .1's "by topic" to this "alphabetical" organization is, in general, an improvement. However, it has its price... the by-topic organization made a lot of small "general discussions" possible, some of which I suspect either are repeated several times, or are omitted. As you will see in XSI, repeitition in a standard has some big risks and should be avoided if at all possible. So should omission. Action: Take extra care to be sure that words that appeared in the base .1 and .2 standards appear exactly the same number of times in this version that they did in the original. (That is, if they were repeated, repeat them, if not, DON'T repeat them, but be sure they are included once.) I suspect that this will cause an increase in the "Genaral Topics" and related chapters. So be it. (As you will see there are a lot of other reasons below to require that a very careful comparison of the base documents with this version to assure that everything was carried forward needs to be done.) _____________________________________________________________________________ Comment Enhancement Request Number 5 donnte@microsoft.com Bug in XBDd3 (rdvk# 99) [DT-XBD-3] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ISO and IEEE staff have been communicating over style issues. D3 has been submitted to WG15 for R&C. D4 will be submitted for formal CD registration and final CD ballot. If ISO have any concerns, they should address them at this point. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: Referring to ERN 6 from last time... It appears that most of the ISO issues have been cleaned up, but some remain. I believe that as soon as a draft incorporating the approved changes from this cycle is completed, it should be taken (hand-carried, if possible) to ISO to confirm that they aren't going to make us rewrite it substantially. I'd hate to put a lot more effort into this format if it won't fly in the long run. Action: Take positive action to be sure that ISO editors will not reject the document. _____________________________________________________________________________ Comment Enhancement Request Number 6 donnte@microsoft.com Bug in XBDd3 (rdvk# 100) [DT-XBD-4] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: In POSIX, the different revision bars were achieved by hand marking the changes. This draft is too large, and it would be too labour intensive to include this. No tools exist to make these multiple diffs. _____________________________________________________________________________ Page: 0 Line: 0 Section: all Problem: Revision bars are too volatile. The changes from D2 to D3 appear to be marked, but not those from D1 to D2. It was not an accident that the "little digits" form of revision bar was used in the original development of POSIX; not everyone saw (or had time to read) every draft. In the Austin Group case, if we're going to have "major" and "minor" review cycles (as we did this time), it would be helpful to have the revision bars survive between major cycles. (It would really have been a problem for me, as I only had time to do XBD last time, except that I planned to (and did) read (or rather, set eyes upon) every word.) Action: Retain revision bars longer (use digits as in POSIX.2). _____________________________________________________________________________ Objection Enhancement Request Number 7 donnte@microsoft.com Bug in XBDd3 (rdvk# 106) [DT-XBD-10] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: "Can" and "may" have different meanings, and are currently being used in the way that ISO and IEEE have defined them. See the terminology section for more information. _____________________________________________________________________________ Page: 1 Line: 8 Section: 1.2 Problem: Well, we got rid of "must". I thought at the same time it was understood that "can" stood under the same cloud (of non-ISO-ness). In any case, it does. (Remember your 1st grade teacher telling you it "may I have a cookie", not "can I have a cookie". This is about granting permission, NOT describing ability.) Action: Convert all "can"s to "may"s. (But be cognizant of my concern with "the application shall"s later in the other volumes.) (Be sure to restore the original IEEE wording; some "can"s may have been "can" before (rightly or wrongly).) Applies to all 3 volumes. _____________________________________________________________________________ Objection Enhancement Request Number 8 donnte@microsoft.com Bug in XBDd3 (rdvk# 107) [DT-XBD-11] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We have defined these terms to be identical in the definitions section. No strong opinions either way, although most people preferred "defined" to "dependant". Decided to go with the suggestion. _____________________________________________________________________________ Page: 1 Line: 12 Section: 1.2 Problem: The TOG change from "implementation-defined" (which is explicit in itself that a "definition" is required) to "implementation dependent" (which doesn't carry the same implication of definition) seems a detriment to the user. Since implementation-defined is a well understood term, both in POSIX and in C, let's not change it unnecessarily here. (Particularly since they're officially synonyms anyway.) Note that I've found at least a couple of instances where the "self-defining" nature of the term "implementation-defined" might have caused an over-specification to be avoided. Action: %s/implementation-dependent/implementation-defined/g _____________________________________________________________________________ Objection Enhancement Request Number 9 donnte@microsoft.com Bug in XBDd3 (rdvk# 101) [DT-XBD-5] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove the requirement to italicize first use _____________________________________________________________________________ Page: xx Line: 721 Section: omitted Problem: I didn't note any uses of this, but the use of "italic first instance" probably violates some or other ISO rule. Action: 1) Remove this. 2) Search for and fix any uses of this convention, consistently with ISO style rules. _____________________________________________________________________________ Editorial Enhancement Request Number 10 donnte@microsoft.com Bug in XBDd3 (rdvk# 102) [DT-XBD-6] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to "the font used here" or "this font" instead of normal. _____________________________________________________________________________ Page: xx Line: 731 Section: omitted Problem: What is "normal" font? Helvetica seems perfectly normal to me; so does courier (computer). Action: Change to either "Roman font" or "The font used here". (I prefer "Roman" as it's more precise, but it's also not quite as well known a term.) (Or... "Roman font, as used here..." I like that best.) _____________________________________________________________________________ Objection Enhancement Request Number 11 donnte@microsoft.com Bug in XBDd3 (rdvk# 103) [DT-XBD-7] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xx Line: 749 Section: omitted Problem: "or warnings" doesn't seem to be used, and in addition because it would affect what's normative for the ISO standard (as opposed to TOG extensions) it shouldn't be used for that. The part about extensions should have a forward ref to the whole discussion of shading. Action: Remove "or warnings" (and any use of this, if any remain). Add forward ref to 1.3.1. _____________________________________________________________________________ Editorial Enhancement Request Number 12 donnte@microsoft.com Bug in XBDd3 (rdvk# 104) [DT-XBD-8] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move this to Informative references, add the year renaming as ISO POSIX-2:1993, and add POSIX-1 as well. Note that these references are only used for informative sections such as change history/rationale etc. _____________________________________________________________________________ Page: xxiv Line: 804 Section: omitted Problem: This becomes a self-reference. Action: Delete _____________________________________________________________________________ Objection Enhancement Request Number 13 donnte@microsoft.com Bug in XBDd3 (rdvk# 105) [DT-XBD-9] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xxv Line: 823 Section: omitted Problem: EMB I've notated this (and some other) problems with "EMB", meaning "embarrassing". This sort of error (and the ones I note below They make the document look sloppy, poorly proofread, and simply not up to the quality of document I want to see produced. The first (and one of 2) authors is "Frank DeRemer". IEEE Style is "Last, First, and Last, First". This got warped along the way so "Frank" became a third author (that didn't exist). Action: Take the reference from the original .2 correctly. (The actual citation here is correct... it's the title.) Fix also in XCU at point of use. (Objection there also.) Also fix in the references section of the other volumes. (Or should there be just one references section, here?) _____________________________________________________________________________ Comment Enhancement Request Number 14 donnte@microsoft.com Bug in XBDd3 (rdvk# 108) [DT-XBD-12] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the definition of will. Any use of the term "will" in informative future directions can be left unchanged. Other (normative) uses should be changed. _____________________________________________________________________________ Page: 2 Line: 57 Section: 1.2 Problem: I believe that that "will" should be treated as an editorial error, not given any stronger status. Action: Delete (and hunt down any remaining ones that are normative). _____________________________________________________________________________ Comment Enhancement Request Number 15 donnte@microsoft.com Bug in XBDd3 (rdvk# 109) [DT-XBD-13] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2 Line: 74 Section: 1.3.1 Problem: This is a weak comment, but worth thinking about... the topic here really is "conformance", and it may better belong in the next chapter. Action: Consult with IEEE editors on how best to present this. _____________________________________________________________________________ Editorial Enhancement Request Number 16 donnte@microsoft.com Bug in XBDd3 (rdvk# 110) [DT-XBD-14] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 117 Section: 1.3.1 Problem: "confidently"... this is pretty blatant salesmanship which doesn't really belong in the ISO standard. Action: Delete "confidently". _____________________________________________________________________________ Objection Enhancement Request Number 17 donnte@microsoft.com Bug in XBDd3 (rdvk# 111) [DT-XBD-15] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The only current use of this is in lp, where it is not required. Therefore delete the PI code here. Correspondinly in XCUd3 page 600 line 22777, delete "such as ...." (PI Code) _____________________________________________________________________________ Page: 5 Line: 197 Section: 1.3.1 Problem: I can't see a better reason to remove something from the standard than to say it doesn't always work. It appears that this in fact has been done, as I don't remember seeing any PI codes. Action: Delete this (and flag any instances of its use for consideration for deletion next time.) _____________________________________________________________________________ Objection Enhancement Request Number 18 donnte@microsoft.com Bug in XBDd3 (rdvk# 112) [DT-XBD-16] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 9 Line: 375, Section: 1.3.2 Problem: I now think I understand these sections. Let me suggest a "that is" sort of example that (a) will tell if *I* have it correct, and (b) help others understand it. (If I got it wrong, then please fix it and add the correct "that is" clauses; if I got it wrong, it's proof that they're really needed!) Action: For line 375, add: "That is, an application which uses this feature is portable only between implementations that provides both options." For line 378, add: "That is, an application which uses this feature is portable between implementations that provide any (or all) of the options." _____________________________________________________________________________ Objection Enhancement Request Number 19 donnte@microsoft.com Bug in XBDd3 (rdvk# 113) [DT-XBD-17] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It is not believed that this text adds any lucidity, especially added in the place suggested. It could be added at 2.1.5, Option Groups, but again, the reviewers did not believe that it added anything useful even here. Another possibility is to add it to the definitions, although this section is the only place that the term is really used. The best place is to add this to the XRAT volume, so they will be added there. _____________________________________________________________________________ Page: 12 Line: 437 Section: 2.1.3 Problem: "Profile" and "self-profile" are concepts that if defined up front here will make the rest of this section far more lucid. Action: Add "A profile of a standard or standards is a codified set of option selections such that by being conformant to a profile, particular classes of users are specifically supported." (Or use the ISO definition, which may be too windy for this.) "This document also provides a large number of options which are grouped into a smaller number of option groups. In effect it has profiled itself (that is, created a self-profile)." _____________________________________________________________________________ Objection Enhancement Request Number 20 donnte@microsoft.com Bug in XBDd3 (rdvk# 114) [DT-XBD-18] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace 477 thru 484 with: The following symbolic constants shall be defined with a value other than -1: _POSIX_JOB_CONTROL _POSIX_SAVED_IDS _POSIX_VDISABLE. Note: the symbols above represent historical options that are no longer allowed as options, but are retained here for backwards compatibility of applications. _____________________________________________________________________________ Page: 13 Line: 478 Section: 2.1.3.1 Problem: Non-optional options do seem a bit odd (and confusing to readers without historical perspective). Remove (and replace). Action: Replace 477 thru 484 with: The following constants shall be defined with a value other than -1: POSIX_JOB_CONTROL _POSIX_SAVED_IDS _POSIX_VDISABLE. Note: the symbols above represent historical options that are no longer allowed as options, but are retained here for backwards compatibility of applications. (I didn't explain them on purpose.) _____________________________________________________________________________ objection Enhancement Request Number 21 ajosey@rdg.opengroup.org Bug in XBDd3 (rdvk# 32) {aj-option-groups} Mon, 17 Apr 2000 15:32:18 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the text for XBDd3 page 19 lines 694-803 with the following: Realtime The Realtime Option Group is denoted by the symbolic constant _XOPEN_REALTIME. This Option Group includes a set of realtime functions drawn from options within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). Where entire functions are included in the Option Group, the NAME section is marked with REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. An implementation that claims conformance to this Option Group shall set the symbolic constant _XOPEN_REALTIME to a value other than -1. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_ASYNCHRONOUS_IO _POSIX_FSYNC _POSIX_MAPPED_FILES _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MEMORY_PROTECTION _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS If the symbolic constant _XOPEN_REALTIME is defined to have a value other than -1, then the following symbolic constants shall be defined by the implementation to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x _POSIX_ASYNCHRONOUS_IO _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MESSAGE_PASSING _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS The functionality associated with _POSIX_MAPPED_FILES, _POSIX_MEMORY_PROTECTION, and _POSIX_FSYNC is always supported on XSI-conformant systems. Support of _POSIX_PRIORITIZED_IO on XSI-conformant systems is optional. If this functionality is supported, then _POSIX_PRIORITIZED_IO shall be set to a value other than -1. Otherwise, it shall be undefined. If _POSIX_PRIORITIZED_IO is supported, then asynchronous I/O operations performed by aio_read (), aio_write ( ), and lio_listio ( ) shall be submitted at a priority equal to the scheduling priority of the process minus aiocbp->aio_reqprio. The implementation shall also document for which files I/O prioritization is supported. Advanced Realtime An implementation that claims conformance to this Option Group shall also support the Realtime Option Group. Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS If the implementation supports the Advanced Realtime Option Group then the following symbolic constants shall be defined by the implementation to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x: _POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS If the symbolic constant _POSIX_SPORADIC_SERVER is defined , then the symbolic constant _POSIX_PRIORITY_SCHEDULING shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x If the symbolic constant _POSIX_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x If the symbolic constant _POSIX_MONOTONIC_CLOCK is defined, then the symbolic constant _POSIX_TIMERS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x If the symbolic constant _POSIX_CLOCK_SELECTION is defined, then the symbolic constant _POSIX_TIMERS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x Realtime Threads The Realtime Option Group is denoted by the symbolic constant _XOPEN_REALTIME_THREADS. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING Where applicable, whole pages are marked REALTIME THREADS, together with the appropriate option margin legend for the SYNOPSIS section (see Section 1.3.1 on page 2). An implementation that claims conformance to this Option Group shall set _XOPEN_REALTIME_THREADS to a value other than -1. If the symbol _XOPEN_REALTIME_THREADS is defined to have a value other than -1, then the symbols shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x: _POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING Advanced Realtime Threads An implementation that claims conformance to this Option Group shall also support the Realtime Threads Option Group. Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME THREADS. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER If the symbolic constant _POSIX_THREAD_SPORADIC_SERVER is defined, then the symbolic constant _POSIX_THREAD_PRIORITY_SCHEDULING shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. If the symbolic constant _POSIX_THREAD_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. If the symbolic constant _POSIX_BARRIERS is defined, then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. If the symbolic constant _POSIX_SPIN_LOCKS is defined , then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. If the implementation supports the Advanced Realtime Threads Option Group then the following symbolic constants shall be defined by the implementation to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. _POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER Tracing This Option Group includes a set of tracing functions drawn from options within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). Where entire functions are included in the Option Group, the NAME section is marked with TRACING . Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT If the implementation supports the Tracing Option Group then the following symbolic constants shall be defined by the implementation to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. _POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT _____________________________________________________________________________ Page: 19 Line: 694-803 Section: XSI_Option_Groups Problem: The Open Group Base Working group has reviewed this section and produced an updated set of Option Groups for XSI conformance. Action: Replace the text for XBDd3 page 19 lines 694-803 with the following: Realtime The Realtime Option Group is denoted by the symbolic constant _XOPEN_REALTIME. This Option Group includes a set of realtime functions drawn from options within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). Where entire functions are included in the Option Group, the NAME section is marked with REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. An implementation that claims conformance to this Option Group shall set the symbolic constant _XOPEN_REALTIME to a value other than -1. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_ASYNCHRONOUS_IO _POSIX_FSYNC _POSIX_MAPPED_FILES _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MEMORY_PROTECTION _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS If the symbolic constant _XOPEN_REALTIME is defined to have a value other than -1, then the following symbolic constants shall be defined by the implementation: _POSIX_ASYNCHRONOUS_IO _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MESSAGE_PASSING _POSIX_PRIORITY_SCHEDULING _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS The functionality associated with _POSIX_MAPPED_FILES, _POSIX_MEMORY_PROTECTION, and _POSIX_FSYNC is always supported on XSI-conformant systems. Support of _POSIX_PRIORITIZED_IO on XSI-conformant systems is optional. If this functionality is supported, then _POSIX_PRIORITIZED_IO shall be set to a value other than -1. Otherwise, it shall be undefined. If _POSIX_PRIORITIZED_IO is supported, then asynchronous I/O operations performed by aio_read (), aio_write ( ), and lio_listio ( ) shall be submitted at a priority equal to the scheduling priority of the process minus aiocbp->aio_reqprio. The implementation shall also document for which files I/O prioritization is supported. Advanced Realtime An implementation that claims conformance to this Option Group shall also support the Realtime Option Group. Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS If the implementation supports the Advanced Realtime Option Group then the following symbolic constants shall be defined by the implementation: _POSIX_ADVISORY_INFO _POSIX_CLOCK_SELECTION _POSIX_CPUTIME _POSIX_MONOTONIC_CLOCK _POSIX_SPAWN _POSIX_SPORADIC_SERVER _POSIX_TIMEOUTS _POSIX_TYPED_MEMORY_OBJECTS If the symbolic constant _POSIX_SPORADIC_SERVER is defined , then the symbolic constant _POSIX_PRIORITY_SCHEDULING shall also be defined If the symbolic constant _POSIX_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined If the symbolic constant _POSIX_MONOTONIC_CLOCK is defined, then the symbolic constant _POSIX_TIMERS shall also be defined If the symbolic constant _POSIX_CLOCK_SELECTION is defined, then the symbolic constant _POSIX_TIMERS shall also be defined Realtime Threads The Realtime Option Group is denoted by the symbolic constant _XOPEN_REALTIME_THREADS. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING Where applicable, whole pages are marked REALTIME THREADS, together with the appropriate option margin legend for the SYNOPSIS section (see Section 1.3.1 on page 2). An implementation that claims conformance to this Option Group shall set _XOPEN_REALTIME_THREADS to a value other than -1. If the symbol _XOPEN_REALTIME_THREADS is defined to have a value other than -1, then the symbols shall also be defined: _POSIX_THREAD_PRIO_INHERIT _POSIX_THREAD_PRIO_PROTECT _POSIX_THREAD_PRIORITY_SCHEDULING Advanced Realtime Threads An implementation that claims conformance to this Option Group shall also support the Realtime Threads Option Group. Where entire functions are included in the Option Group, the NAME section is marked with ADVANCED REALTIME THREADS. Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER If the symbolic constant _POSIX_THREAD_SPORADIC_SERVER is defined, then the symbolic constant _POSIX_THREAD_PRIORITY_SCHEDULING shall also be defined If the symbolic constant _POSIX_THREAD_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined If the symbolic constant _POSIX_BARRIERS is defined, then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined If the symbolic constant _POSIX_SPIN_LOCKS is defined , then the symbolic constants _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS shall also be defined If the implementation supports the Advanced Realtime Threads Option Group then the following symbolic constants shall be defined by the implementation: _POSIX_BARRIERS _POSIX_SPIN_LOCKS _POSIX_THREAD_CPUTIME _POSIX_THREAD_SPORADIC_SERVER (If 1q is merged into D4 then add a new Option Group) Tracing This Option Group includes a set of tracing functions drawn from options within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). Where entire functions are included in the Option Group, the NAME section is marked with TRACING . Where additional semantics have been added to existing pages, the new material is identified by use of the appropriate margin legend for the underlying option defined within IEEE Std. 1003.1-200x. This Option Group consists of the set of the following options from within IEEE Std. 1003.1-200x (see Section 2.1.6 on page 22). _POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT If the implementation supports the Tracing Option Group then the following symbolic constants shall be defined by the implementation: _POSIX_TRACE _POSIX_TRACE_EVENT_FILTER _POSIX_TRACE_LOG _POSIX_TRACE_INHERIT _____________________________________________________________________________ objection Enhancement Request Number 22 prindle@voicenet.com Bug in XBDd3 (rdvk# 197) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Use second option. The proposed approach has now been marked up in the AAM XBDd3 ERN #21 above. _____________________________________________________________________________ Page: 20 Line: 738-739 Section: 2.1.5.2 [prindle.xbd-1] Problem: This text is in conflict with IEEE 1003.1d and IEEE 1003.1j. Those standards require their new option symbols to be defined a 200ymmL. This text also allows the symbols to be defined as -1, which I don't think was intended. This problem also applies to: page 21 line 795-796 section 2.1.5.2 XSI Option Groups Action: The harmonization issue: Either require all option symbols to be defined with the date of approval of this standard, or require all to be an unspecified value other than -1. It appears you've attempted the latter, but the harmonization question is raised later in as an open issue. If the requirement that these symbols be defined to a date is deleted, this should appear in change history somewhere, but this section has no change history at the moment, so one should be added. In any case, this text should at least require that the symbols not be -1: If the symbol _XOPEN_REALTIME is defined to have a value other than -1, the the following symbolic constants shall be defined by the implementation to have values other than -1. OR If the symbol _XOPEN_REALTIME is defined to have a value other than -1, the the following symbolic constants shall be defined by the implementation to have the value 200ymmL, the date of approval of IEEE Std 1003.1-200x. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 23 donnte@microsoft.com Bug in XBDd3 (rdvk# 115) [DT-XBD-19] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 31 Line: 1159 Section: 3.4 Problem: Sure... I'll take a shot at it. Action: Add: "Implementation defined mechanisms that are layered upon the access control mechanisms defined here, but which do not grant permissions beyond those defined herein, although they may further restrict them." _____________________________________________________________________________ Comment Enhancement Request Number 24 donnte@microsoft.com Bug in XBDd3 (rdvk# 116) [DT-XBD-20] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add: "An implementation-defined mechanism that is independent of the access control mechanisms defined herein, and which if enabled on a file may either restrict or extend the permissions of a given user. This standard defines when such mechanisms can be enabled and when they shall be disabled." _____________________________________________________________________________ Page: 33 Line: 1193 Section: 3.12 Problem: In for a penny... Action: Add: "Implementation defined mechanisms that are independent of the access control mechanisms defined herein, and which if enabled on a file may either restrict or extend the permissions of a given user. This standard defines when such mechanisms can be enabled and when they shall be disabled." _____________________________________________________________________________ Objection Enhancement Request Number 25 donnte@microsoft.com Bug in XBDd3 (rdvk# 117) [DT-XBD-21] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept point 1 remove the margin code shading. Reject part 2. This definition came from .1c, and it is not clear that the alternative wording is completely compatible with that. Reject this alternative definition -- out of scope. _____________________________________________________________________________ Page: 35 Line: 1250 Section: 3.28 Problem: 1) This definition is generally useful (even if only used by threads at the moment). Since it doesn't normatively affect anything to remove the shading and margin code, do that. 2) The first sentence is close, but not quite. Action: 1) Remove margin code, shading. 2) Replace first sentence with: "A signal that is not attributable to the actions of the thread handling the signal." (That is, a raise() (kill() of self) would be reasonably considered a synchronous signal, but a SIGSEGV handled by a thread other than the one generating it would not be synchronous to the handling thread (although it is synchronous to the GENERATING thread.) _____________________________________________________________________________ Editorial Enhancement Request Number 26 donnte@microsoft.com Bug in XBDd3 (rdvk# 118) [DT-XBD-22] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is consistently used, and is felt useful. _____________________________________________________________________________ Page: 37 Line: 1288, Section: 3.38, Problem: This sort of note that simply replaces a quick look into the table of contents or index doesn't really help the document very much. Although I wouldn't object to an inline hyperlink (because thumbing thru a webpage and using your fingers for bookmarks is harder) the paper copy doesn't need notes like this for things that are trivially found by tried and true indexing technology. (Note, there ARE such notes in other places that point to not-so-obvious places to look that are fine with me. It's just these really obvious ones that seem a waste.) Action: Delete. _____________________________________________________________________________ Comment Enhancement Request Number 27 donnte@microsoft.com Bug in XBDd3 (rdvk# 119) [DT-XBD-23] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change the last sentence by deleting the phrase "On a system based on the ISO/IEC 9945-2:1993 standard,", so it now starts "A byte may be larger..." _____________________________________________________________________________ Page: 45 Line: 1490 Section: 3.86 Problem: The note here is rationale. Also the ref to the 1993 standard should be cleaned up... this was the X/Open spec referencing POSIX, and now that this is POSIX... Action: 1) Convert to rat. 2) Delete "On a system..." and replace with the -199x rationale that says what this refers to. _____________________________________________________________________________ Comment Enhancement Request Number 28 donnte@microsoft.com Bug in XBDd3 (rdvk# 120) [DT-XBD-24] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Its a clear statement, and the difference needs to be here. _____________________________________________________________________________ Page: 45 Line: 1507 Section: 3.89 Problem: The note is rationale. Action: Make rationale. _____________________________________________________________________________ Comment Enhancement Request Number 29 donnte@microsoft.com Bug in XBDd3 (rdvk# 121) [DT-XBD-25] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This was to felt to be useful and retained. _____________________________________________________________________________ Page: 46 Line: 1520 Section: 3.91 Problem: This note is what the index is for. Action: Delete. _____________________________________________________________________________ Comment Enhancement Request Number 30 donnte@microsoft.com Bug in XBDd3 (rdvk# 122) [DT-XBD-26] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 49 Line: 1616 Section: 3.111 Problem: This note is useless. Either it's import is far more than I think it is and it needs expansion, or it's banal to the point of confusion. Action: Delete. _____________________________________________________________________________ Objection Enhancement Request Number 31 donnte@microsoft.com Bug in XBDd3 (rdvk# 123) [DT-XBD-27] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move 1632-1640 to XCU section 2.3 following page 39 line 1364. Do not add note. _____________________________________________________________________________ Page: 50 Line: 1632 Section: 3.115 Problem: This makes a normative requirement on the application, and as such cannot be in the definitions. There's also a lot of rationale tangled up in this text. Action: 1) Move (and clean up) 1632-1640 to XCU 2.3 (to the extent it's not already there). 2) Add: Note "There are limitations on the use of adjacent ( (as in "((") in ...2.3". _____________________________________________________________________________ Objection Enhancement Request Number 32 donnte@microsoft.com Bug in XBDd3 (rdvk# 124) [DT-XBD-28] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add defn: "Current Job: in the context of job control, the job that will be used as the default for the fg or bg utilities. There is at most one current job. See also Job Control Job Id." _____________________________________________________________________________ Page: 52 Line: 1666 Section: 3.123 Problem: The text below is needed to address objections made in XCU, and to define terms used without definition in Job Control Job Id (3.207) Action: Add new definition: Current Job: in the context of job control, the job that will be used as the default for the fg or bg. There is at most one current job. Identified on output with the character "+". See also Job Control Job Id. _____________________________________________________________________________ Comment Enhancement Request Number 33 donnte@microsoft.com Bug in XBDd3 (rdvk# 125) [DT-XBD-29] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the term is not actually used anywhere in the standard except in this definition. Delete the term. _____________________________________________________________________________ Page: 53 Line: 1687 Section: 3.130 Problem: I support this change (of course... I wrote it.). Action: Change as noted. _____________________________________________________________________________ Comment Enhancement Request Number 34 donnte@microsoft.com Bug in XBDd3 (rdvk# 126) [DT-XBD-30] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The group felt this was useful and should be retained. _____________________________________________________________________________ Page: 54 Line: 1730 Section: 3.137 Problem: The first note (line 1725) is helpful. The notes at 1727 and 1730 are clutter. Action: Delete 1727, 1730. _____________________________________________________________________________ Objection Enhancement Request Number 35 donnte@microsoft.com Bug in XBDd3 (rdvk# 128) [DT-XBD-32] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete "peripheral" from defn. Change the last sentence "Drivers are..." to the end of the paragraph into a note, leaving "may" _____________________________________________________________________________ Page: 55 Line: 1742 Section: 3.141 Problem: Let's try again one; ERN #49 and #50 from last time. The definition of "may" is provided by ISO and all the other standards bodies involved. It is specifically reserved to grant permission for a user of the standard to do something, but not to require it. This use of "may" doesn't grant permission in any useful way, any more than a statement that "a standard conforming headlight may have some metal in it". (Of course it does.) This is just an observation, and "might" is the proper word to use. (There are specific guidelines in the various standards on standards Action: "may" -> "might". _____________________________________________________________________________ objection Enhancement Request Number 36 ajosey@opengroup.org Bug in XBDd3 (rdvk# 92) {bwg2000-004p1} Sun, 30 Apr 2000 09:01:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: There is no need to add this definition as the text within XCU added to support this is self-referential _____________________________________________________________________________ Page: 57 Line: 1793 Section: 3.155 Problem: The Open Group Base Working Group has approved resolution BWG2000-004 (see http://www.opengroup.org/platform/resolutions/ ). This introduces the concept of executable scripts using the #! notation as an XSI extension. Further changes are submitted against XCU to complete this, this change request adds a new definition in support of it. Action: Add the following definition to XBD in alphabetical order: Executable Script: An executable file of which the first two characters are "#!" as defined in the portable character set. Some systems only recognize an executable script when it starts with the four bytes `#! /'. See the Shell Command Language Introduction Section 2.1 on page XX. _____________________________________________________________________________ comment Enhancement Request Number 37 prindle@voicenet.com Bug in XBDd3 (rdvk# 198) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use no margin codes within definitions (note that they are also not used within informative text (rationale/appusage etc) _____________________________________________________________________________ Page: 57 Line: 1802 Section: 3.158 [prindle.xbd-2] Problem: The association between definitions and options is weak at best. In many cases, (e.g. 3.222) there is no association shown even though the definition directly applies to an optional set of facilities, and a previous definition related to the same facilities, but more of a generic definition of an action (3.219) does show options in the margin. Action: Decide how to handle definitions which describe terms used in optional facilities. Alternatives: a) Use no margin codes in definitions. b) Use shading and margin codes on definition text which has no meaning except in the context of an optional facility. Do not shade/code if term being defined generically even if nothing in the standard would reference the term except in the context of an option. c) Use shading and margin codes on all text of definitions of terms which are referenced only by optional facilities. d) ??? Any other suggestions Frankly, I favor a) because the margin codes here don't seem to add a lot to the definitions and because POSIX.1-1996 etal don't qualify defs. However, c) does tend to alleviate confusion associated with definitions like 3.210 which clearly require the reader to know the context before understanding under what circumstances the definition (as given) applies. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 38 donnte@microsoft.com Bug in XBDd3 (rdvk# 127) [DT-XBD-31] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: These xrefs are felt useful _____________________________________________________________________________ Page: 58 Line: 1830 Section: 3.165 Problem: This whole bunch of notes is clutter. Action: Delete. _____________________________________________________________________________ Editorial Enhancement Request Number 39 donnte@microsoft.com Bug in XBDd3 (rdvk# 129) [DT-XBD-33] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: By IEEE aand ISO rules, cannot contain X-refs normatively, exept to other defns. Therefore all X-refs to things that are not other definitions must be notes. _____________________________________________________________________________ Page: 62 Line: 1931 Section: 3.188 Problem: The text itself needs to reference the General Terminal Interface. Action: Delete Note, add sentence at 1930: "This is defined in more detail in General Terminal Interface in Chapter 11.". _____________________________________________________________________________ Objection Enhancement Request Number 40 donnte@microsoft.com Bug in XBDd3 (rdvk# 130) [DT-XBD-34] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to "the directory specified by the HOME environment variable." _____________________________________________________________________________ Page: 64 Line: 1971 Section: 3.197 Problem: See ERN 58 from last time. The definition of the cd command defines "cd" and "cd ~" (via pathname expansion) as equivalent to "cd $HOME". In both cases, if $HOME is unspecified, the result is unspecified. In any reasonable sense, the value of $HOME is the user's home directory, as any testsuite would have to assume that whatever is in $HOME is definitive. I don't have a problem with defining the *initial value* at the time of an (unspecified!) login process of $HOME as coming from the user database, but as a matter of practice, the ways in which $HOME is used are far more definitive of the home directory. (As far as I know there is no standard command to get the directory named in the user database (although it is available via getpwent() and friends), and I would be VERY surprised to find that any user that did explicitly set $HOME would be pleased if it wasn't his home directory from then on.) Action: Change the definition: (This is somewhat edited from last time.) "The directory named in $HOME, which is initially set (at the time of an unspecified login process) to a value found in the user database. The value found in the user database is also the initial current working directory after the completion of the (unspecified) login process." _____________________________________________________________________________ Objection Enhancement Request Number 41 Andries.Brouwer@cwi.nl BUG in XBDd3 - Host Byte Order (rdvk# 4) [] Sat, 11 Mar 2000 01:44:44 +0100 (MET) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change to: Host Byte Order The arrangement of bytes in any int type when using a specific machine architecture. NOTE: Two common methods of byte ordering are "big endian" and "little endian". "Big endian" is a format for storage of binary data in which the most significant byte is placed first, with the rest in descending order. "Little endian" is a format for storage or transmission of binary data in which the least significant byte is placed first, with the rest in ascending order. change/add: Network Byte Order The way of representing any int type such that, when transmitted over a network via a network endpoint, the the int type is transmitted as an appropriate number of octets with the most significant octet first, followed by any other octets in descending order of significance. NOTE: This order is more commonly known as "big endian" ordering. _____________________________________________________________________________ Page: 64 Line: 1977 Section: 3.198 Problem: This definition may be a definition of host bit order but says nothing about bytes. (In fact it is not a definition of host bit order either since there is no dependence on the host. It is just the definition of the binary representation of a number.) Action: Write something like: The native representation of an integer: the unsigned integer m is the representation in host byte order of the sequence of unsigned character values b_0, ..., b_{n-1} when n equals sizeof(m) and after storing m via an (unsigned int *) and casting this pointer to (unsigned char *), b_0, ..., b_{n-1} is the sequence of bytes found at the address pointed to by this unsigned char *. [Yes, this is (too) ugly, and I hope someone says it better. But some ugliness must be involved. In normal decent programming practice it never plays a role whether the machine is bigendian or little endian. Such things only play a role in programs containing questionable casts.] [In case this is changed, one may also reconsider Network Byte Order.] _____________________________________________________________________________ Editorial Enhancement Request Number 42 Andries.Brouwer@cwi.nl BUG in XBDd3 - Host Byte Order (rdvk# 3) [] Sat, 11 Mar 2000 01:44:44 +0100 (MET) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_41 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 64 Line: 1977 Section: 3.198 Problem: The formula has two high asterisks. There should either be three low asterisks or (preferably) no asterisks at all. Action: Delete the two asterisks. _____________________________________________________________________________ objection Enhancement Request Number 43 prindle@voicenet.com Bug in XBDd3 (rdvk# 199) [prindle.xbd-3] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_37 Reject_____ Rationale for rejected or partial changes: all shading will be removed from defns. See ERN 37. _____________________________________________________________________________ Page: 68 Line: 2066,2069 Section: 3.223 Problem: Line 2065 is optional based on MF. Line 2069 is optional based on MF|SHM|TYM. Here is an example of how complicated the shading of definitions can get (see [prindle.xbd-2]). Action: Shade line 2066 and mark MF. Mark line 2069 MF|SHM|TYM. This fixes the immediate problem, but then do the appropriate thing based on resolution of [prindle.xbd-2]). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 44 prindle@voicenet.com Bug in XBDd3 (rdvk# 204) [prindle.xbd-8] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 71 Line: 2141-2142 Section: 3.239 Problem: These amplifying lines should be in a note. They are also confusing. Action: Make these lines a note. Change "The batch system" to "The term Batch System". ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 45 prindle@voicenet.com Bug in XBDd3 (rdvk# 205) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the term appears to be unused; delete the entire definition, and 3.242 _____________________________________________________________________________ Page: 72 Line: 2154-2157 Section: 3.243 [prindle.xbd-9] Problem: The second sentence onward should be in a note (rqmts). Action: Put all but first sentence fragment in a note. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 46 donnte@microsoft.com Bug in XBDd3 (rdvk# 131) [DT-XBD-35] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: make the second para of the supplied replacement a note. Change "reads to devices" to "reads from devices", so: Replace with: A property of an open file description that causes it to either perform the requested action or return an indication that the action could not be immediately performed, in either case returning without delay (other than normal scheduling delays) from the call. Note: The exact semantics are dependent on the the type of file associated with the open file. For data reads from devices such as ttys and FIFOs a successful return usually indicates that data sufficient to satisfy the read was immediately available. Similarly, for writes, that space to perform (at least part of) the write was available, and for networking not to await protocol events (for example, acknowledgments) to occur. _____________________________________________________________________________ Page: 73 Line: 2178 Section: 3.246 Problem: This definition is networking-specific, even though it's used for several file types. Action: Replace with: A property of an open file description that causes it to either perform the requested action or return an indication that the action could not be immediately performed, in either case returning without delay (other than normal scheduling delays) from the call. The exact semantics are dependent on the the type of file associated with the open file. For data reads to devices such as ttys and FIFOs it usually indicates that data sufficient to satisfy the read was immediately available. Similarly, for writes, that space to perform (at least part of) the write was available, and for networking not to await protocol events (for example, acknowledgments) to occur. _____________________________________________________________________________ editorial Enhancement Request Number 47 prindle@voicenet.com Bug in XBDd3 (rdvk# 206) [prindle.xbd-10] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_46 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 73 Line: 2179-2181 Section: 3.246 Problem: Only the first sentence conveys the definition. The rest are amplifying info related to networking functions. There are similar semantics related to open(), mq_open(), etc. Action: Move all but first sentence to a note. If possible, make the note more generic, to include non-blocking alternatives in general. E.g.: change "protocol events (for example acknowledgements)" to "completion of all phases of an operation", or something like that. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 48 nick@usenix.org Bug in XBDd3 (rdvk# 16) {Usenix3} Thu, 13 Apr 2000 02:58:13 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move to 4.5 after line 3439, as part of the same para. Add "In the context of this \*(St" after first sentence of defn. Delete all rationale at 2280-2288. _____________________________________________________________________________ Page: 77 Line: 2275-2277 Section: 3.272 Problem: Although the text allowing implementation-defined treatment of //path-name was under the deinition of path name in 1003.1a, it more rightly belongs in the pathname resolution general concept. Action: Move the sentence "A path name that begins with two successive slashes may be interpreted in an implementation-dependent manner, although more than two leading slashes shall be treated as a single slash." to Path Name Resolution in 4.5 _____________________________________________________________________________ Comment Enhancement Request Number 49 donnte@microsoft.com Bug in XBDd3 (rdvk# 132) [DT-XBD-36] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_48 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 77 Line: 2275 Section: 3.272 Problem: The text here is a bit confusing (with two levels of "...but"). Action: Try replacing "Multiple..." with: "If the pathname begins with exactly 2 leading slashes it is given special treatment as defined in Section 4.5." (Otherwise we end up making a normative requirement in the definitions! See a change there as well.) _____________________________________________________________________________ objection Enhancement Request Number 50 prindle@voicenet.com Bug in XBDd3 (rdvk# 213) [prindle.xbd-17] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_48 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 77 Line: 2279-2282 Section: 3.272 Problem: This so-called rationale is actually change history. Action: Move it to the change history section at the end of the definitions. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 51 prindle@voicenet.com Bug in XBDd3 (rdvk# 207) [prindle.xbd-11] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add new definition Attributes of an object that determine the privilege necessary to access or manipulate the object. _____________________________________________________________________________ Page: 78 Line: 2300 Section: 3.277 Problem: Need new def. Action: Try: Attributes of an object that determine the privilege necessary to access or manipulate the object in various ways. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 52 donnte@microsoft.com Bug in XBDd3 (rdvk# 133) [DT-XBD-37] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Previous Job: in the context of job control, the job that will be used as the default for the fg or bg utilities if the current job exits. There is at most one previous job. See also Job Control Job Id. _____________________________________________________________________________ Page: 79 Line: 2396 Section: 3.285 Problem: The text below is needed to address objections in XCU, and to define terms used undefined in Job Control Job Id (3.207) Action: Add new definition: Previous Job: in the context of job control, the job that will be used as the default for the fg or bg utilities if the current job exits. There is at most one previous job. Identified on output with the character "-". See also Job Control Job Id. _____________________________________________________________________________ Objection Enhancement Request Number 53 donnte@microsoft.com Bug in XBDd3 (rdvk# 134) [DT-XBD-38] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Adopt "read-write lock" as the generic term, delete lines 2442-2443 Do a global search for reader-writer lock and replace with read-write lock _____________________________________________________________________________ Page: 84 Line: 2443 Section: 3.310 Problem: This paints over a strictly editorial error. Choose one term and use it everywhere. (I actually prefer this one, but don't care much.) Action: %s/Read-Write Lock/Reader-Writer lock/gi delete lines 2443 and 2444. _____________________________________________________________________________ Objection Enhancement Request Number 54 donnte@microsoft.com Bug in XBDd3 (rdvk# 135) [DT-XBD-39] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete "that augments the BASE signals mechanism"; change "existing signals function" to "existing signal functions". _____________________________________________________________________________ Page: 84 Line: 2458 Section: 3.314 Problem: "BASE" is undefined. I'm not sure what to propose here but those who were thru the X/Open process should find it obvious. Action: Andrew? _____________________________________________________________________________ Objection Enhancement Request Number 55 donnte@microsoft.com Bug in XBDd3 (rdvk# 136) [DT-XBD-40] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: we consulted with the IEEE editor, and ... the definition makes it clear that this is a noun (it start "A collection..." which can only be used in a noun context). _____________________________________________________________________________ Page: 85 Line: 2464 Section: 3.316 Problem: Here we need to distinguish (at least for those not fully fluent in English) "record" vs. "record" (with accents on different syllables, making one a noun the other a verb). In this case, the noun is intented. Action: Add "(n)" or whatever IEEE/ISO says is the proper way to indicate the noun. _____________________________________________________________________________ Comment Enhancement Request Number 56 donnte@microsoft.com Bug in XBDd3 (rdvk# 137) [DT-XBD-41] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Defn: A path name not beginning with a slash. _____________________________________________________________________________ Page: 86 Line: 2493 Section: 3.325 Problem: I'll try it again. Action: A path name not beginning with a slash, and which is thus resolved with respect to the current working directory of the process. _____________________________________________________________________________ Comment Enhancement Request Number 57 donnte@microsoft.com Bug in XBDd3 (rdvk# 138) [DT-XBD-42] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The x-refs are felt to be useful. _____________________________________________________________________________ Page: 87 Line: 2528 Section: 3.333 Problem: These notes are not helpful. Action: Delete clutter. _____________________________________________________________________________ Objection Enhancement Request Number 58 donnte@microsoft.com Bug in XBDd3 (rdvk# 139) [DT-XBD-43] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: keep first sentence as defn. Move all the remainder to general concepts called Scheduling Policy, add a note referring to the Scheduling Policy general concept. _____________________________________________________________________________ Page: 88 Line: 2551 Section: 3.339 Problem: This appears to be a normative requirement in definitions. Move elsewhere (if not already some place else) and reference from here to indicate that there are additional requirements. Action: 1) Move this paragraph to a new section 4.8, on scheduling policy. 2) Collect with that other general concepts associated with scheduling. An alternative (easier now, but in the long run probably less satisfactory) is to move this into XSI someplace in 2.9.6. Let the thread experts call the details. _____________________________________________________________________________ Editorial Enhancement Request Number 59 jeffcope@microsoft.com bug in XBDd3 (rdvk# 221) [Copeland-xbd-1] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Move the whole of 3.342 to General Concepts , Seconds Since the Epoch (since Epoch is a defn, this can be a general concept). Change the x-ref in defn of Epoch to Note to point to the new section. Change Notes to Reviewers to a Note, and remove the first sentence. _____________________________________________________________________________ Page: 89 Line: 2576 Section: 3.342 Problem: The derivation for the approximation of time_t is not completely obvious. In particular, the last term for the 400 year rule has the odd term of 299 in it. An comment now would go a long way towards preventing confusion later. (The expression is correct, by the way.) Action: Add the following sentence after "... leap seconds is unspecified." "Because the base of 1970 and offset of 1900 for tm_year is not on an even 400-year boundary, the last term in this approximation is non-intuitive." Alternately, retain the commentary on line 2580-2583 but label it Rationale. _____________________________________________________________________________ Comment Enhancement Request Number 60 donnte@microsoft.com Bug in XBDd3 (rdvk# 140) [DT-XBD-44] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete all the shaded words. Introduce new general concept "Semaphores". Move 3.344 and 3.345 to the General Concepts Semaphores section, plus the intro sentence from 3.343. Add sentence explaining difference between XSI and SEM semaphores _____________________________________________________________________________ Page: 90 Line: 2566 Section: 3.343 Problem: If this definition stands as is (which I wouldn't mind) then System V semaphores are excluded (which I also wouldn't mind). Action: Your call. _____________________________________________________________________________ editorial Enhancement Request Number 61 prindle@voicenet.com Bug in XBDd3 (rdvk# 208) [prindle.xbd-12] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_60 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 90 Line: 2586-2588 Section: 3.343 Problem: I think I know what was intended here, but this doesn't read right. Action: Add "; it is " after the word program. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 62 prindle@voicenet.com Bug in XBDd3 (rdvk# 209) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove all the O_ASYNC stuff. Delete 3.354 the definition of signal driven IO. In XSH remove O_ASYNC in 2.10.7 (Cathy knows how...) and delete last para in XSH 2.10.4 (lines 2918-2924). _____________________________________________________________________________ Page: 92 Line: 2635-2641 Section: 3.354 [prindle.xbd-13] Problem: Well, I'm certainly confused. There is no O_ASYNC flag defined in so no way to get a socket into such a mode. If this is an oversight, it needs to be added to . Even if that were done, this definition is deficient because it doesn't cover all cases where the signal would be generated - for example in the case of a listening socket that can now do an accept without blocking because of a pending connection request. I can't find O_ASYNC defined in a Solaris release, so I suspect this mode doesn't really exist. Action: Either delete this whole definition, or add O_ASYNC to and use words derived from the paragraph at the bottom of page 84 of XSHd3 instead (they are more complete WRT what can cause the signal). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 63 prindle@voicenet.com Bug in XBDd3 (rdvk# 210) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The rationale will be moved to XRAT in the next draft. _____________________________________________________________________________ Page: 97-101 Line: 2791-2991 Section: 3.382 [prindle.xbd-14] Problem: Rationale in a definition is rather unusual. Either it should be with symlink() in XSH, or by itself in XRAT. Action: Move all instances of rationale that occur in a definition to either the RATIONALE section of the corresponding function, or the equivalent section of XRAT. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 64 donnte@microsoft.com Bug in XBDd3 (rdvk# 141) [DT-XBD-45] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use dot-dot -> "filename dot-dot" _____________________________________________________________________________ Page: 101 Line: 2951 Section: 3.382 Problem: ". . " (note spaces). Action: Convert to ".." or (preferably) "dot-dot". _____________________________________________________________________________ Comment Enhancement Request Number 65 donnte@microsoft.com Bug in XBDd3 (rdvk# 142) [DT-XBD-46] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 101 Line: 2956 Section: 3.382 Problem: Is this observation about vendor effort still relevant? Action: Delete. _____________________________________________________________________________ Objection Enhancement Request Number 66 donnte@microsoft.com Bug in XBDd3 (rdvk# 143) [DT-XBD-47] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_25 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 103 Line: 3023 Section: 3.389 Problem: Similarly to Asynchronous signal... Action: Change to: "A signal that is attributable to the thread which is handling it, and which is handled immediately upon its generation. Note: timer and I/O completion signals are considered attributable to the timer or I/O system." _____________________________________________________________________________ comment Enhancement Request Number 67 nick@usenix.org Bug in XBDd3 (rdvk# 15) {Usenix1} Thu, 13 Apr 2000 02:45:03 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_37 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 106 Line: 3131 Section: 3.408 Problem: In general, option shading a definition means (at least to me!) that the definition is only used when the option is supported. The definition for timeout should not be option shaded; a timeout is a timeout, and should be defined here. Not all interfaces that take a timeout parameter are TMO restricted (e.g. select()). Please see also Usenix2. Action: Remove the option shading TMO for timeout definition. _____________________________________________________________________________ objection Enhancement Request Number 68 nick@usenix.org Bug in XBDd3 (rdvk# 29) {Usenix2} Thu, 13 Apr 2000 02:52:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "the the" should be "the". so: Replace the two definitions of timeouts with the following (notice also that the definition should be singular, not plural): Timeout: A method of limiting the length of time an interface will block (see 3.77, Blocked process or thread). _____________________________________________________________________________ Page: 106 Line: 3131 Section: 3.408 Problem: Neither definition of timeout is particular helpful. Action: Replace the two definitions of timeouts with the following (notice also that the definition should be singular, not plural): Timeout: A method of limiting the the length of time an interface will block (see 3.77, Blocked process or thread). _____________________________________________________________________________ comment Enhancement Request Number 69 prindle@voicenet.com Bug in XBDd3 (rdvk# 211) [prindle.xbd-15] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_37 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 107 Line: 3136 Section: 3.408 Problem: Comment on Note to reviewers. Action See [prindle.xbd-2] WRT shading in defs. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 70 Don.Cragun@eng.sun.com Bug in XBDd3 (rdvk# 217) [DWC-1] Mon, 1 May 2000 23:03:03 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 107 Line: 3144-3145 Section: 3.411(Timers) Problem: (overlapping definitions) Subclause 3.122 defines the term "CPU-Time Timer", subclause 3.409 defines the term "Timer", and subclause 3.411 defines the term "Timers". There is no way in the text in XSH6 to determine whether use of the term "timers" refers to a plural use of the term "Timer" or a singular use of the term "Timers". Furthermore, the definition of timers: "A functionality and determinism improvement facility to increase the resolution and capabilities of the time-base function." makes no sense. There is no time-base() function. No use of the term "timers" that I have found in XSH6 seems to be used to mean "a functionality and determinism improvement facility to increase the resolution and capabilities" of any function. Action: Delete the definition of the term "Timers" from P107, L3143-3145. ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 71 donnte@microsoft.com Bug in XBDd3 (rdvk# 144) [DT-XBD-48] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: move all of 3.426 to general concepts. Do make the editorial substition as suggested in XCU ern 15 [DT-XCU-11] (change "In all cases" to "When a variable assignment is done") _____________________________________________________________________________ Page: 109 Line: 3209-3218 Section: 3.426 Problem: Shall in definition. Action: Move to XCU. Delete here and fix as noted for line 1610 of XCU. _____________________________________________________________________________ Editorial Enhancement Request Number 72 Don.Cragun@eng.sun.com Bug in XBDd3 (rdvk# 218) [DWC-2] Mon, 1 May 2000 23:03:03 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 3.444 ( as covered by front matter, page xx) _____________________________________________________________________________ Page: 113 Line: 3307 Section: 3.444 Problem: (four notations are described; two are defined) The definition text describes the meaning of [n,m], (n,m], [n,m), and (n,m), but only the first and third are mentioned in the title of the definition. Action: Change "[n,m] and [n,m)" on P113, L3307 to "[n,m], (n,m], [n,m), and (n,m)". ------------------------------------------------------------------------------ _____________________________________________________________________________ Objection Enhancement Request Number 73 donnte@microsoft.com Bug in XBDd3 (rdvk# 145) [DT-XBD-49] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_72 Reject_____ Rationale for rejected or partial changes: Observation: contrast this ERN with DT-XBD-2, note also that Rationale will be far removed from the online text in the next draft when the XRAT is a separate volume. _____________________________________________________________________________ Page: 113 Line: 3307 Section: 3.444 Problem: EMB Redundant with line 744. Notes: There are a number of these text duplications. Some within rationale or within the main text, as well as quite a few between rationale and the main text. In any of these cases (but particularly in the first two cases) I find this simply embarrassing. It makes the document look sloppy, poorly proofread, and simply not up to the quality of document I want to see produced. Just reading what's actually there would catch most of these; it's a waste of time to have 50 people all have to read them. As a matter of having an actual action, I've always suggested deleting the earlier (and thus non-rationale) copy of duplicated text (unless *I* had a reason to do otherwise). I really don't strongly care which is removed, but if it is the rationale copy, careful thought should be given to be sure that the remaining copy is appropriate to its new context. Action: Choose one, any one. (I have no preference, but since it's notation, not a definition, IEEE probably does.) _____________________________________________________________________________ Objection Enhancement Request Number 74 donnte@microsoft.com Bug in XBDd3 (rdvk# 146) [DT-XBD-50] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: restore 1003.1 1996, page 30, sect 2.3.2 wording. _____________________________________________________________________________ Page: 115 Line: 3347 Section: 4.1 Problem: The current wording in .1 is "is" rather than "shall" based. However, it would be good to shallify as much as possible. Action: Shallify this whole section. _____________________________________________________________________________ Objection Enhancement Request Number 75 donnte@microsoft.com Bug in XBDd3 (rdvk# 147) [DT-XBD-51] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: replace last sentence with "See sect 3.120 on page 51" _____________________________________________________________________________ Page: 116 Line: 3401 Section: 4.4 Problem: "is defined" referring to a definition is redundant. Action: Delete clutter. _____________________________________________________________________________ Objection Enhancement Request Number 76 donnte@microsoft.com Bug in XBDd3 (rdvk# 148) [DT-XBD-52] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_48 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 117 Line: 3412 Section: 4.5 Problem: The special case for // got lost. (Not that I really mind.) The group decided last time to retain it, but it's not here. Since retaining it at this time is at best counter-intuitive, I ask that rationale be generated. (Since I don't see a reason to retain it, I can't write it.) Action: Add: If a pathname begins with exactly two slashes, the meaning is implementation-defined. Three or more slashes shall be treated as if they were a single slash. Add rationale for retaining // as a special case. (Action on someone who supported its retention at the last meeting.) _____________________________________________________________________________ Objection Enhancement Request Number 77 Don.Cragun@eng.sun.com Bug in XBDd3 (rdvk# 219) [DWC-3] Mon, 1 May 2000 23:03:03 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 117 Line: 3414 Section: 4.5 Problem: (Path Name Resolution and _POSIX_NO_TRUNC) Now that P1003.1a has aligned with FIPS requirements, there is no need to mention _POSIX_NO_TRUNC while describing Path Name Resolution. Action: Change the paragraph on P117, L3413-3418 to: The interpretation of a path name component is dependent on the value of {NAME_MAX} and _POSIX_NO_TRUNC associated with the path prefix of that component. If any path name component is longer than {NAME_MAX}, the implementation shall consider this an error. ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 78 Andries.Brouwer@cwi.nl pathname resolution (rdvk# 1) [] Thu, 2 Mar 2000 03:39:11 +0100 (MET) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add text: "If the system detects a loop in the path name resolution process, it shall set errno to [ELOOP] and return an error indication. The same may happen if during the resolution process more symbolic links were followed than the implementation allows. This implementation-defined limit shall not be smaller than SYMLOOP_MAX." _____________________________________________________________________________ Page: 117 Line: 3434 Section: Path_Name_Resolution Problem: No text for ELOOP Action: Add text: "If the system detects a loop in the path name resolution process, it will set errno to [ELOOP] and return an error indication. The same may happen if during the resolution process more symbolic links were followed than the implementation allows. This implementation-defined limit must not be smaller than SYMLOOP_MAX." _____________________________________________________________________________ Comment Enhancement Request Number 79 Andries.Brouwer@cwi.nl pathname resolution (rdvk# 2) [] Thu, 2 Mar 2000 03:39:11 +0100 (MET) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 118 Line: 3461 Section: Path_Name_Resolution Problem: The sentence is incorrect (interchanges directory and parent dir). Action: Replace "and is represented by the name dot-dot in that" by "which is represented by the name dot-dot in the first". _____________________________________________________________________________ Comment Enhancement Request Number 80 donnte@microsoft.com Bug in XBDd3 (rdvk# 149) [DT-XBD-53] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 122 Line: 3520 Section: 5 Problem: "left" is a bit colloquial, and potentially ambiguous (as in "to the left"). Action: "left on the line" -> "remaining on the line". _____________________________________________________________________________ Objection Enhancement Request Number 81 donnte@microsoft.com Bug in XBDd3 (rdvk# 150) [DT-XBD-54] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Proposed text: A set of symbolic names for characters in Table 6.2, which is called the portable character set, is used in character description text of this International Standard. The first eight entries in Table 6.2 are defined in ISO/IEC 6429 and the rest of the characters is defined in ISO/IEC 10646-1. Table 6.2: Portable character set Symbolic name Glyph UCS Description NULL (NUL) BELL (BEL) BACKSPACE (BS) CHARACTER TABULATION (HT) CARRIAGE RETURN (CR) LINE FEED (LF) LINE TABULATION (VT) FORM FEED (FF) SPACE ! EXCLAMATION MARK " QUOTATION MARK # NUMBER SIGN $ DOLLAR SIGN % PERCENT SIGN & AMPERSAND ' APOSTROPHE ( LEFT PARENTHESIS ) RIGHT PARENTHESIS * ASTERISK + PLUS SIGN , COMMA - HYPHEN-MINUS - HYPHEN-MINUS . FULL STOP . FULL STOP / SOLIDUS / SOLIDUS 0 DIGIT ZERO 1 DIGIT ONE 2 DIGIT TWO 3 DIGIT THREE 4 DIGIT FOUR 5 DIGIT FIVE 6 DIGIT SIX 7 DIGIT SEVEN 8 DIGIT EIGHT 9 DIGIT NINE : COLON ; SEMICOLON < LESS-THAN SIGN = EQUALS SIGN > GREATER-THAN SIGN ? QUESTION MARK @ COMMERCIAL AT A LATIN CAPITAL LETTER A B LATIN CAPITAL LETTER B C LATIN CAPITAL LETTER C D LATIN CAPITAL LETTER D E LATIN CAPITAL LETTER E F LATIN CAPITAL LETTER F G LATIN CAPITAL LETTER G H LATIN CAPITAL LETTER H I LATIN CAPITAL LETTER I J LATIN CAPITAL LETTER J K LATIN CAPITAL LETTER K L LATIN CAPITAL LETTER L M LATIN CAPITAL LETTER M N LATIN CAPITAL LETTER N O LATIN CAPITAL LETTER O

p LATIN SMALL LETTER P q LATIN SMALL LETTER Q r LATIN SMALL LETTER R s LATIN SMALL LETTER S t LATIN SMALL LETTER T u LATIN SMALL LETTER U v LATIN SMALL LETTER V w LATIN SMALL LETTER W x LATIN SMALL LETTER X y LATIN SMALL LETTER Y z LATIN SMALL LETTER Z { LEFT CURLY BRACKET { LEFT CURLY BRACKET | VERTICAL LINE } RIGHT CURLY BRACKET } RIGHT CURLY BRACKET ~ TILDE This International Standard uses other character names than the above, but only in an informative way, for example in examples, to illustrate use of characters beyond the portable character set with the facilities of this International Standard. _____________________________________________________________________________ Page: 127 Line: 3643 Section: 6.1 Problem: This is where I'd look for a resolution to ERN 26 from last time. (This was the AI on HPA to add text indicating the correspondence between 10646 names and the names we use.) I don't see anything, although I may have missed it. Action: Complete AI or point me to its result. _____________________________________________________________________________ Objection Enhancement Request Number 82 donnte@microsoft.com Bug in XBDd3 (rdvk# 151) [DT-XBD-55] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: if you have a system that supports mixed locales, it is not merely a matter of mixing locales but of knowing at all times which locale a particular operation relates to; this wording was deliberate and intentional, and it should not be changed. _____________________________________________________________________________ Page: 128 Line: 3695 Section: 6.1 Problem: This seems a bit overbroad: it appears to say to me that if I define two locales, one in (say) EBCDIC and the other in (say) ASCII, that even though I don't access more than one such locale on the machine, that if I access either one of them, that my results are unspecified. Action: "accessing those locales" -> "accessing more than one of those locales". _____________________________________________________________________________ Comment Enhancement Request Number 83 donnte@microsoft.com Bug in XBDd3 (rdvk# 153) [DT-XBD-57] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The PAR allows use of the base documents. _____________________________________________________________________________ Page: 128 Line: 3699 Section: 5 Problem: It appears that this clause (that all portable characters are bytes) has the effect of completely disallowing a (pure, not UTF-8)) Unicode implementation of the standard. I don't believe that the intent is to disallow that, although it might require another option to have it make sense. Action: I don't know enough at this point to make a sensible suggestion, but if true and the intent is NOT to change it, it at least deserves a note. I'm willing to try to craft wording given guidance on the consensus of what should be said. _____________________________________________________________________________ Objection Enhancement Request Number 84 donnte@microsoft.com Bug in XBDd3 (rdvk# 152) [DT-XBD-56] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN 83 _____________________________________________________________________________ Page: 128 Line: 3699 Section: 5 Problem: See ERN 93 from last time. I still don't see any reason to require that portable characters be positive. It's not in .1-1990 or -1993. At a minimum, make it an XSI extension, but I think it's wrong even for that. (Or justify it on the grounds of portability of a *reasonable* application.) (Note that the pragmatic effect of this on EBCDIC systems is to force char type to be unsigned.) Using XPG4 as a precedent for the ISO standard (unless authorized by the PAR) not very solid ground. Action: Remove the statement about characters having positive values. Failing that, make it XSI. _____________________________________________________________________________ Objection Enhancement Request Number 85 jeffcope@microsoft.com bug in XBDd3 (rdvk# 222) [Copeland-xbd-2] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: See ERN 83 _____________________________________________________________________________ Page: 128 Line: 3700 Section: 6.1 Problem: Despite Mark Brown's inquiries with Gary Miller as action item 9907-07, and the corresponding ANSI C requirement, we still have a problem here. It is completely unrelated to the (quoting from Gary's comments) "restriction ... that C-compilers had to be able to recognize and parse basic strings such as printf format strings ..." (which I believe is a red herring). If "the [character] value is stored in an object of C-language type char, it is guaranteed to be positive (except the NUL..." means that either (a) all characters in the portable set have values less than 128 (for an 8-bit byte) or (b) chars must be unsigned. This is simply not true for EBCDIC in signed chars. Action: I'm not sure how to fix this for non-ASCII signed chars in 8-bit bytes. Perhaps I'm the only one who sees a problem here. We could start by adding, "which implies that some encodings only work in implementations with unsigned chars." _____________________________________________________________________________ Objection Enhancement Request Number 86 jeffcope@microsoft.com bug in XBDd3 (rdvk# 223) [Copeland-xbd-3] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove here and on p 130 _____________________________________________________________________________ Page: 128 Line: 3711 Section: 6.1 Problem: "... (although in the case of just one [charmap] file on the system, -f is not useful.)" This isn't true if other than the portable names in table 6-1 have been used. That is, even if all the locales on the system are expressed in terms of ISO 8859-1, and hence the only charmap file is named iso8859.1, the localedef source can still be built using symbolic character names like . (Also, pg 130, ln 3783) Action: Remove this parenthetical comment. _____________________________________________________________________________ Objection Enhancement Request Number 87 donnte@microsoft.com Bug in XBDd3 (rdvk# 154) [DT-XBD-58] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Reject the proposed change, instead the existing text will be shallified. _____________________________________________________________________________ Page: 130 Line: 3790 Section: 6.4 Problem: This paragraph is a lot of hand waving, but little that it would be easy to claim was really a standard. Action: Replace with: Each symbolic name specified in Table 6-1 on page 127 shall be included in the file and shall be mapped to a unique coding value. The glyphs {, }, _, -, /, \, ., ^, [Ed- use CW font for these] have more than one symbolic name; all symbolic names for each such glyph shall be included, each with identical encoding. If some or all of the control characters identified in table 6-2 are supported by the implementation, the symbolic names and their corresponding encoding values shall be included in the file. Some of the encodings associated with the symbolic names in table 6-2 may be the same as characters found in table 6-1; both names shall be provided for each such encoding. _____________________________________________________________________________ Objection Enhancement Request Number 88 donnte@microsoft.com Bug in XBDd3 (rdvk# 155) [DT-XBD-59] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 131 Line: 3814 Section: 6.4 Problem: shallification Action: change to read shall always be 1. _____________________________________________________________________________ editorial Enhancement Request Number 89 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 70) {al-03} Fri, 28 Apr 2000 14:20:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 132 Line: 3856 Section: 6.4 Problem: Context is : 3854 The encoding part is expressed as one (for single-byte character values) or more concatenated 3855 decimal, octal, or hexadecimal constants in the following formats: 3856 "%cd%d", , 3857 "%cx%x", , 3858 "%c%o", , Using C scanf rules, %x and %o deal with unsigned quantities, where %d deals with signed quantities. To be consistent, we should use %u to specify the decimal value. Action: Change "%cd%d" To "%cd%u" _____________________________________________________________________________ Objection Enhancement Request Number 90 jeffcope@microsoft.com bug in XBDd3 (rdvk# 224) [Copeland-xbd-4] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Reject. The wording is as per P1003.2b . We will add a reviewers note that a problem has been noted (quote the text below) and that when .2b is a standard an interp should be filed. _____________________________________________________________________________ Page: 132 Line: 3893 Section: 6.4 Problem: In the description of WIDTH, certainly the intent is not to restrict width values to only "the printable characters in the coded character set specified in Table 6-1 ... and Table 6-2..." That makes WIDTH simply uninteresting. Action: Change this to "the printable characters specified between the CHARMAP and END CHARMAP statements." _____________________________________________________________________________ Editorial Enhancement Request Number 91 jeffcope@microsoft.com bug in XBDd3 (rdvk# 225) [Copeland-xbd-5] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "code point values..." to "numerical code point values..." on line 3912 _____________________________________________________________________________ Page: 133 Line: 3913 Section: 6.4 Problem: >From the example on line 3906-3911, we have "The code point values to inclusive (, , , and so on) are also assigned a width of 1." It's not completely clear, considering subsequent discussion in Chapter 7, whether we mean the lexical or numerical range of characters. Action: Change "code point values..." to "numerical code point values..." _____________________________________________________________________________ editorial Enhancement Request Number 92 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 72) {al-04} Fri, 28 Apr 2000 14:05:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 135 Line: 3992 Section: 6.4 Problem: Page 132 reads as 3859 Decimal constants are represented by two or three decimal digits, preceded by the escape 3860 character and the lowercase letter d; for example, "\d05", "\d97",or"\d143". 3861 Hexadecimal constants are represented by two hexadecimal digits, preceded by the escape 3862 character and the lowercase letter x; for example, "\x05", "\x61", or "\x8f".Octal 3863 constants are represented by two or three octal digits, preceded by the escape character; for 3864 example, "\05", "\141", or "\217". In a portable charmap file, each constant represents an 8- 3865 bit byte. Implementations supporting other byte sizes may allow constants to represent values 3866 larger than those that can be represented in 8-bit bytes, and to allow additional digits in 3867 constants. Since there are changing bars, I assume the latter had been recently modified. However the rationale (page 135) reads as: 3992 [...] Each of the constants includes two or more digits to account 3993 for systems in which the byte size is larger than 8 bits. For example, a Unicode ( system that has 3994 defined 16-bit bytes may require six octal, four hexadecimal, and five decimal digits. which I read as referring to another text, probably the former version. Action: Change "Each of the constants includes two or more digits to account" To "Provision is made for more digits to account" _____________________________________________________________________________ Editorial Enhancement Request Number 93 donnte@microsoft.com Bug in XBDd3 (rdvk# 159) [DT-XBD-63] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 135 Line: 3993 Section: 6.4.1 Problem: isolated meaningless "(" after "Unicode". Action: delete. _____________________________________________________________________________ Editorial Enhancement Request Number 94 jeffcope@microsoft.com bug in XBDd3 (rdvk# 226) [Copeland-xbd-6] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_93 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 135 Line: 3993 Section: 6.4.1 Problem: Extraneous open paren in "Unicode ( system" Action: remove _____________________________________________________________________________ Editorial Enhancement Request Number 95 jeffcope@microsoft.com bug in XBDd3 (rdvk# 227) [Copeland-xbd-7] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "no multi-byte characters, and so on" to "no multi-byte characters." remove "shall" from 4001 _____________________________________________________________________________ Page: 135 Line: 4003 Section: 6.4.1 Problem: Misplaced close double quote, I think. Action: Change "no multi-byte characters, and so on" to "no multi-byte characters," and so on. _____________________________________________________________________________ Editorial Enhancement Request Number 96 jeffcope@microsoft.com bug in XBDd3 (rdvk# 228) [Copeland-xbd-8] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: editor will use appropriate font (bold) _____________________________________________________________________________ Page: 135 Line: 4005 Section: 6.4.1 Problem: Bad font Action: change "the width specification" to have "WIDTH" in constant width caps _____________________________________________________________________________ Objection Enhancement Request Number 97 donnte@microsoft.com Bug in XBDd3 (rdvk# 157) [DT-XBD-61] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: "Undefined" is adequate. _____________________________________________________________________________ Page: 137 Line: 4049 Section: 7.1 Problem: This really doesn't say how really bad an error mixing locale categories with incompatible character sets is. Action: Rewrite to: Locale categories using different character sets are incompatible. If any two locale categories which are defined in different character sets are in use at the same time (where some locale dependent operation actually occurs in the application) the results are undefined. Implementations are encouraged to diagnose such a situation. Similarly, if the codeset used for data to be processed by a locale dependent operation is different than that defined for the appropriate locale categories, the results are undefined, and again implementations are encouraged to detect and diagnose the situation where possible. _____________________________________________________________________________ Objection Enhancement Request Number 98 donnte@microsoft.com Bug in XBDd3 (rdvk# 156) [DT-XBD-60] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: wording is adequate _____________________________________________________________________________ Page: 137 Line: 4050 Section: 7.1 Problem: It should work to use exactly one locale, always. Action: Change to read "utilizing more than one of these categories". See also objection to 4049. _____________________________________________________________________________ Objection Enhancement Request Number 99 donnte@microsoft.com Bug in XBDd3 (rdvk# 158) [DT-XBD-62] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the term is being used consistently with the approved terminology, i.e. an application writer can do this. _____________________________________________________________________________ Page: 141 Line: 4170 Section: 7.3 Problem: can Action: -> may. (I'm sure I've missed many of these; editor please hunt down.). _____________________________________________________________________________ editorial Enhancement Request Number 100 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 71) {al-05} Fri, 28 Apr 2000 14:20:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 141-142 Line: 4180-4234 Section: 7.3 Problem: Page 132 reads as 3859 Decimal constants are represented by two or three decimal digits, preceded by the escape 3860 character and the lowercase letter d; for example, "\d05", "\d97",or"\d143". 3861 Hexadecimal constants are represented by two hexadecimal digits, preceded by the escape 3862 character and the lowercase letter x; for example, "\x05", "\x61", or "\x8f".Octal 3863 constants are represented by two or three octal digits, preceded by the escape character; for 3864 example, "\05", "\141", or "\217". In a portable charmap file, each constant represents an 8- 3865 bit byte. Implementations supporting other byte sizes may allow constants to represent values 3866 larger than those that can be represented in 8-bit bytes, and to allow additional digits in 3867 constants. Since there are changing bars, I assume the latter had been recently modified. However the similar texts pages 141 and 142 read differently: 4180 3. A character can be represented as an octal constant. An octal constant is specified as the 4181 escape character followed by two or more octal digits. Each constant represents a byte 4182 value. [...] 4186 4. A character can be represented as a hexadecimal constant. A hexadecimal constant shall be 4187 specified as the escape character followed by an x followed by two or more hexadecimal 4188 digits. Each constant shall represent a byte value. [...] 4193 5. A character can be represented as a decimal constant. A decimal constant shall be specified 4194 as the escape character followed by a d followed by two or more decimal digits. Each 4195 constant represents a byte value. I suggest to align the latter with the former. Action: Line 4181, Change "more" to "three" Line 4187, Suppress "or more" Line 4194, Change "more" to "three" Add between line 4199 and 4200 a new paragraph: "Implementations supporting other byte sizes may allow constants to represent values larger than those that can be represented in 8-bit bytes, and to allow additional digits in constants." Change lines 4233-4234 "Each of the constants includes two or more digits to account" To "Provision is made for more digits to account" _____________________________________________________________________________ Comment Enhancement Request Number 101 donnte@microsoft.com Bug in XBDd3 (rdvk# 160) [DT-XBD-64] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is the same as in the original .2. See ERN 4 [DT-XBD-2]. _____________________________________________________________________________ Page: 142 Line: 4230 Section: 7.3 Problem: EMB Although it is different chapters, it's still embarrassing to have the same paragraph repeated within a couple of pages. (See line 3988). Action: In this case replace with: "As for state dependent character encodings, two digit constants are required. (See [prior similar text] )". _____________________________________________________________________________ comment Enhancement Request Number 102 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 73) {al-06} Fri, 28 Apr 2000 16:01:11 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 143-146 Line: 4279-4395 Section: 7.3.1 Problem: Page 139 reads as 4100 The use of symbolic names for characters in the tables does not imply that the POSIX locale must 4101 be described using symbolic character names, but merely that it may be advantageous to do so. However, if the code listing pages 147-148 and the unnumbered tables pages 149 to 151 do use the symbolic character names, the textual description pages 143 to 146 do not. I believe this is a possible choice lines 4279, 4286, 4297, 4345, 4380, 4382, 4393 and 4395 for readibility reasons. However this is not correct for the other references. Action: Line 4281 page 143, Change "A to Z" To " to " Line 4288 page 144, Change "a to z" To " to " Line 4299-4300, Change "0, 1, 2, 3, 4, 5, 6, 7, 8, and 9" To ", , , , , , , , , " Line 4301, Change "0 to 9" To " to " Line 4312-4313, Change "space, form-feed, newline, carriage-return, tab, and vertical-tab" To ", , , , , and " Line 4350-4351 page 145, Change "A, B, C, D, E, F, a, b, c, d, e, f" To ", , , , , , , , , , , " Line 4351, Change "0 to 9" To " to " Line 4352, Change "A to F" To " to " Also line 4352, Change "a to f" To " to " Line 4388 page 146, Change "a to z" To " to " Lines 4388-4398, Change "A to Z" To " to " _____________________________________________________________________________ editorial Enhancement Request Number 103 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 68) {al-02} Wed, 19 Apr 2000 12:50:20 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 144 Line: 4312-4313 Section: Locale Problem: [ if it even matters, I use the PDF version ] These lines read as "In the POSIX locale, at a minimum, the characters space, form-feed, newline, carriage-return, tab and vertical-tab are included." I believe the character should be specified with the symbolic notation, enclosed with <>. Action: Change "the characters space, form-feed, newline, carriage-return, tab and vertical-tab" To "the characters , , , , and " _____________________________________________________________________________ Objection Enhancement Request Number 104 donnte@microsoft.com Bug in XBDd3 (rdvk# 161) [DT-XBD-65] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: use of can is consistent with agreed terminology _____________________________________________________________________________ Page: 145 Line: 4334 Section: 7.3.1 Problem: "can". Action: -> "may". _____________________________________________________________________________ editorial Enhancement Request Number 105 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 74) {al-07} Fri, 28 Apr 2000 16:20:31 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 145 Line: 4339-4340 Section: 7.3.1 Problem: Lines 4339-4341 read as 4339 In a locale definition file, characters specified for the keywords upper, lower, 4340 alpha, digit, xdigit, punct, and the character are automatically 4341 included in this class. [...] In effect, that means that a character, which is otherwise not classified as alpha/punct/digit can be declared as graph *without* being declared as print. Which will result in an incompatibility with the C standard (isprint/isgraph). Table 7.1 line 4414, which is specifying the same matters, fortunately require that the "graph" class is automaticaly included in the "print" class. I believe the text should be aligned with the table. Action: Change "the keywords upper, lower, alpha, digit, xdigit, punct, and the character" To "the keywords upper, lower, alpha, digit, xdigit, punct, graph, and the character" _____________________________________________________________________________ Objection Enhancement Request Number 106 donnte@microsoft.com Bug in XBDd3 (rdvk# 162) [DT-XBD-66] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: use of can is consistent with agreed terminology; it is not believed necessary to add a separate term "cannot", or to explain that it is the opposite of "can". _____________________________________________________________________________ Page: 145 Line: 4365 Section: 7.3.1 Problem: "cannot" This is more serious, because it is NOT a "can" but rather a "shall". Action: -> "shall not". Editor, please find and correct all instances of "cannot", "can not", and other spelling variations in normative text and convert to "shall not". (Using proper judgment, of course.) _____________________________________________________________________________ comment Enhancement Request Number 107 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 75) {al-08} Fri, 28 Apr 2000 16:29:17 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: There is no need for a separate alnum class, since its a combination of alpha and digit as noted on line 4432. _____________________________________________________________________________ Page: 147 Line: 4406-4417 Section: 7.3.1 Problem: The class "alnum" is missing in the table 1. Action: Insert a new line between 4410 and 4411, with the following content: "alnum - - - - x x x A A - x" Lines 4406-4417, insert a new column between 'digit' and 'space', with the following settings: 4406 alnum 4407 (upper) A 4408 (lower) A 4409 (alpha) A 4410 (digit) A 4411 (space) x 4412 (cntrl) x 4413 (punct) x 4414 (graph) - 4415 (print) - 4416 (xdigit) - 4417 (blank) x _____________________________________________________________________________ comment Enhancement Request Number 108 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 78) {al-10} Fri, 28 Apr 2000 17:55:01 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is the POSIX locale , and as such it does not get extended in the manner suggested. Extended versions can be derived from this, and become locales other than the POSIX locale, however the guaranteed definition of the POSIX locale is this documented here. Compatibility with existing implementations is also another factor why we would not want to change this. _____________________________________________________________________________ Page: 147 Line: 4427-28 Section: 7.3.1 Problem: Lines 4081-4083 page 138 read: 4084 The tables in Section 7.3 on page 140 describe the characteristics and behavior of the POSIX 4085 locale for data consisting entirely of characters from the portable character set and the control 4086 character set. For other characters, the behavior is unspecified. The text in the description of the various categories, from page 143 to page 146, clearly indicates with expressions like "at a minimum" and "all the characters [...] are included", that further extensions of the POSIX locale, in particular beyond the portable character set, is allowed (of course, such extensions are *unspecified*, so *NOT PORTABLE*; but they are allowed). On the other hand, lines 4427-4428 page 147 4427 The character classifications for the POSIX locale follow; the code listing depicting the localedef 4428 input, the table representing the same information, sorted by character. may imply that the tables are to be taken litterally. And indeed this is how some POSIX "gurus" I have asked are viewing the things. I believe the extensibility is desirable, if for no other reason to allow the isw*** wide-character classification functions to return meaningful values outside the portable set, even in the POSIX locale. So I believe the current text that allows unspecified behaviour is welcome. But I would also dispell any misunderstandings, in particular with the last sentence I quoted. Action: Line 4427-4428 page 147, Change "The character classifications for the POSIX locale follow;" To "The classifications of the characters of the portable set for the POSIX locale follow;" _____________________________________________________________________________ comment Enhancement Request Number 109 Antoine.Leca@renault.fr Bug in XBDd3 (rdvk# 76) {al-09} Fri, 28 Apr 2000 16:45:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This is a normative requirement from the existing base documents and to change it is out of scope. Please file an interpretation request against 1003.2 if you believe the standard is either wrong or inconsistent (see http://www.pasc.org/interps/). _____________________________________________________________________________ Page: 147-150 Line: 4449-4453, Section: 7.3.1 Problem: The (control) characters to and to are not required to be supported by the implementation. In particular, lines 3850-3851 page 132 reads as 3850 [...] If the control characters commonly associated with the symbolic names in Table 3851 6-2 on page 130 are supported by the implementation, the symbolic name and the corresponding 3852 encoding value shall be included in the file. As a result, the code listing page 147-148 and the tables page 148&150 should not be listed in the "portable POSIX LC_CTYPE specification". Note that I have kept and , which *are* in the portable set. By the way: the common assumption that the C standard *requires* characters 0 to 31 and 127 to be classified by iscntrl is wrong: the relevant text only appears in a note, i.e. non normative. Action: Remove everything from the first semicolon to the end of line 4450, thus leaving: " " Delete lines 4451 to 4453 Delete lines 4485 to 4490 Delete lines 4498 to 4515 Delete line 4615 _____________________________________________________________________________ Objection Enhancement Request Number 110 donnte@microsoft.com Bug in XBDd3 (rdvk# 163) [DT-XBD-67] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: this ERN refers to itself, we cannot figure out where the duplicated text is, as such this is non-responsive. _____________________________________________________________________________ Page: 152 Line: 4652 Section: 7.3.1 Problem: EMB This is a repeat of the text at 4652. Action: Remove this. (However, the text at 4652 should be "shall-ified") _____________________________________________________________________________ Objection Enhancement Request Number 111 donnte@microsoft.com Bug in XBDd3 (rdvk# 164) [DT-XBD-68] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: remove the second (informative) copy of this text _____________________________________________________________________________ Page: 162 Line: 5090 Section: 7.3.2 Problem: EMB This is redundant with text at 4770. Action: Delete at 4770. _____________________________________________________________________________ Comment Enhancement Request Number 112 donnte@microsoft.com Bug in XBDd3 (rdvk# 165) [DT-XBD-69] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: this is obvious and does not need to be stated _____________________________________________________________________________ Page: 168 Line: 5396 Section: 7.3.4 Problem: The glitch that there is no year 0 is not as broadly known as it should be; it can't hurt to to add... Action: Add: "The Julian/Gregorian calendar has no year 0.". _____________________________________________________________________________ Objection Enhancement Request Number 113 donnte@microsoft.com Bug in XBDd3 (rdvk# 166) [DT-XBD-70] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 170 Line: 5444 Section: 7.3.5.2 Problem: Redundant with line 5386 Action: Delete. _____________________________________________________________________________ Objection Enhancement Request Number 114 donnte@microsoft.com Bug in XBDd3 (rdvk# 167) [DT-XBD-71] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: drop XSI shading / marking, as its part of .2b alignment _____________________________________________________________________________ Page: 176 Line: 5686 Section: 7.4.1 Problem: Is charclass an XSI extension or not? At line 4360 it is not marked XSI, here it is. Which is correct? Action: Fix one. _____________________________________________________________________________ objection Enhancement Request Number 115 prindle@voicenet.com Bug in XBDd3 (rdvk# 212) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: should be page 108 delete the term "Unblocked Mode" 3.418 _____________________________________________________________________________ Page: 180 Line: 3166-3167 Section: 3.418 [prindle.xbd-16] Problem: A mode is a function? What is the context of this (EINTR, EAGAIN, ???) Where did this come from and what concept is it trying to define? Notice that there is no corresponding "Blocked Mode". I'm confused! Action: Delete this; or establish the context then generate a comprehensible definition. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 116 jeffcope@microsoft.com bug in XBDd3 (rdvk# 229) [Copeland-xbd-9] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (changes have been marked on the draft) on lines 6071-6074 change LOWER->LOWER-CASE and UPPER->UPPER-CASE; insert before 6031. add after 6007 : "collating-symbol " _____________________________________________________________________________ Page: 185 Line: 6077 Section: 7.5 Problem: Proposed replacement for the example on line 6069 is clearer. Perhaps a mention of stxfrm() or strcoll() in the "(for compare purposes)" parenthetical would be useful? Action: Substitute the explanation on line 6080-6089 for the one on 6068-6076, with the further addition of a sentence like "Interfaces like strcoll() use this evaluation stategy to compare strings." _____________________________________________________________________________ Editorial Enhancement Request Number 117 jeffcope@microsoft.com bug in XBDd3 (rdvk# 230) [Copeland-xbd-10] Mon, 1 May 2000 16:37:11 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 189 Line: 6223 Section: 8.2 Problem: Missing space Action: change "LC_*(LC_COLLATE..." to LC_* (LC_COLLATE..." _____________________________________________________________________________ Editorial Enhancement Request Number 118 donnte@microsoft.com Bug in XBDd3 (rdvk# 168) [DT-XBD-72] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 190 Line: 6263 Section: 8.2 Problem: The interspersion of blank horizontal lines between the shading makes it very difficult to read. I don't know if the tools can be corrected to fix this, but if it is possible it would improve the document. This is just the worst one I noted, but there are may other instances. Action: Fix tools, if possible. _____________________________________________________________________________ Editorial Enhancement Request Number 119 donnte@microsoft.com Bug in XBDd3 (rdvk# 169) [DT-XBD-73] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the lack of space was very intentional. _____________________________________________________________________________ Page: 194 Line: 6452 Section: 8.3 Problem: Given "spaces inserted for clarity" above, improve readability by inserting one. Action: "stdoffset" -> "std offset". _____________________________________________________________________________ Objection Enhancement Request Number 120 donnte@microsoft.com Bug in XBDd3 (rdvk# 170) [DT-XBD-74] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: the second copy will move to XRAT, and thus be far from the other copy! _____________________________________________________________________________ Page: 203 Line: 6736 Section: 9.2 Problem: EMB Redundant. Action: Delete 6736-6747 in favor of 6668. _____________________________________________________________________________ comment Enhancement Request Number 121 drepper@redhat.com Bug in XBDd3 (rdvk# 69) {ud-42} Thu, 27 Apr 2000 14:01:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: the standard(s) is/are currently correct; _____________________________________________________________________________ Page: 206 Line: 6843-6845 Section: Basic Problem: The starting point for looking at this text was actually glob which let to fnmatch which in turn refers to regular expressions. But I should start from the beginning. In glibc 2.2 we have now an implementation of fnmatch which follows the standard strictly. But this leads to problems with the users since this behaviour is very different from what they expect. Take the following example. You have the six files a b c A B C in a directory. Now you execute glob ("[a-c]", ...) in this directory. The result is as expected for the C/POSIX locale. But as soon as the LC_COLLATE category is using a different locale the results are very surprising, negatively in most cases. Following ISO 14651 most locale definitions will have a sorting order which sorts first according to the base character and only at a later level by case. I.e., since the base character of 'a' and 'A' is the same while that of 'a' and 'b' is not, 'b' sorts after 'A' and 'B' sorts after 'a'. For the above six names one gets either a A b B c C or A a B b C c as the sorting order. So far so good. Some people have problems with that as well but I can cope with that. The problem starts when the collation is applied in the fnmatch to a range in a bracket expression. For the above example this means: [a-c] matches all characters which collate between 'a' and 'c', boundaries included. The draft standard (and POSIX) text is: 7. A range expressions represents the set of collating elements that fall between two elements in the collating element order of the current locale, includsive. A range expression shall be expressed as the starting points separated by a hyphen. Going back to the example this means the the glob() call returns either a A b B c or a B b C c which is very surprising and sometimes desastrous (just imagine rm [a-c]). I know that the standard says that range expressions should not be used but tell this to the users who lost files because of this. Action: I guess what I'm mainly interested in is to hear how the Unix vendors are handling this case. I have not been able to determine this myself since there is no complete locale implementation on any of the system I have access to (at least the data is not there and cannot be created since localedef input files aren't there either). I would like to see some change in this area just because everybody implementing this correctly will take a lot of heat from the users. I see two possibilities: 1. change the bracket handling definition to more or less imitate the behaviour of the POSIX locale. I.e., for x-y (x and y are meant as variables, I have cursive available here) include all the character in the range from x to y in the charset of the compilation environment. 2. add a new flag to fnmatch() which toggles the strict handling of range expressions on. I.e., it should be off by default. If not selected the behaviour should be as described in point 1. I do not yet describe here a concrete wording since I'm sure there will be resistance to make any such change. But if I'm really the only one who has implemented this completely I would like people to take this report seriously. I don't want to be responsible for data loss as in possible with `rm [a-c]*` and therefore will knowingly diverge from the standard if nothing is changed. I'm open to other suggestions who to fix this problem. _____________________________________________________________________________ comment Enhancement Request Number 122 Sandra Martin O iso-8859-1 (rdvk# 77) Thu, 27 Apr 2000 14:52:54 -0400 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 6843-6845 Section: Basic_Regular_Expressions Problem: I disagree very strongly with this comment (ud-42). The behavior Ulrich finds surprising has been shipping on Unix systems for 8-10 years. While I cannot speak for other vendors, for Tru64 Unix, we do NOT hear complaints from users about it. Rather, the range expression matching lets users get the results that are appropriate for their locales. A collation definition inherently defines what is in a range, so I also disagree with the suggestion that range expressions only work as if in the POSIX locale. If my collation order is: /* removing case to simplify the example */ a a b c g ch I certainly would not expect that the range expression [a-c] would only match a b c but that is what the POSIX range expression would match. Remember, the POSIX locale has only portable characters. The current behavior is well-defined and has been in use for a long time. Since it has been in use, users obviously are either continuing to use the POSIX locale and get the (in essence) ASCII results they're accustomed to getting, or they are using other locales and understand that the behavior differs according to those locales. Action: Reject this request, IMO, changing this behavior would be wrong. _____________________________________________________________________________ comment Enhancement Request Number 123 keld@dkuug.dk Bug in XBDd3 (rdvk# 232) {ks-1} Fri, 28 Apr 2000 03:13:46 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 206 Line: 6843-6845 Section: Basic Problem: I think what Ulrich is describing is not really a question on the behaviour of the shell, but rather which default locale to give the shell. I have a suspicion that systems like AIX, Tru 64 etc defaults to the POSIX locale for installation and that people need to do something rather willingly to set up other locales. So only the really NLS committed gets the dangerous behaviour. I might be wrong. I think the problem as Ulrich encounters it now, is that Linux shells for collating is beginning to honour LC_COLLATE. Maybe an advice to Ulrich is then to ask the user when setting up the machine whether s/he wants this behaviour from the shell. Could then be a special flag/environment variable to the shell not to honor the given LC_COLLATE. I am pretty sure that most applications want to sort capital and small letters together. As the LC_COLLATE environment variable is inherited from the forking process, this then better be what has been around for ages also in Linux. Action: None. _____________________________________________________________________________ Editorial Enhancement Request Number 124 donnte@microsoft.com Bug in XBDd3 (rdvk# 171) [DT-XBD-75] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete 6847-6852 _____________________________________________________________________________ Page: 207 Line: 6886 Section: 9.3.5 Problem: EMB Redundant with 6851 Action: Delete 6851. _____________________________________________________________________________ Comment Enhancement Request Number 125 donnte@microsoft.com Bug in XBDd3 (rdvk# 172) [DT-XBD-76] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 207 Line: 6918 Section: 9.3.6 Problem: For clarity, change: Action: "begins with the nth '\('" -> "begins with the nth '\(' from the beginning of the pattern". _____________________________________________________________________________ Editorial Enhancement Request Number 126 Don.Cragun@eng.sun.com Bug in XBDd3 (rdvk# 220) [DWC-4] Mon, 1 May 2000 23:03:03 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 208 Line: 6920 Section: 9.3.6 Problem: (BREs Matching Multiple Characters) The \ character and the " character at the start of the expression on this line overlap each other. Action: Change the start of the BRE on P208, L6920 so it is clear that the expression is: "\(.*\)\1$" ------------------------------------------------------------------------------ _____________________________________________________________________________ Comment Enhancement Request Number 127 donnte@microsoft.com Bug in XBDd3 (rdvk# 173) [DT-XBD-77] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: there seems little point in making this move _____________________________________________________________________________ Page: 209 Line: 6961 Section: 9.3.7 Problem: This comes in the middle of the list (as if the precedence order was discussed between + and * in an expression). Action: Move (to the end of the section after anchoring). _____________________________________________________________________________ Objection Enhancement Request Number 128 donnte@microsoft.com Bug in XBDd3 (rdvk# 174) [DT-XBD-78] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 222 Line: 7417 Section: 10.1 Problem: Redundant with 7388. Action: Delete at 7388. _____________________________________________________________________________ Objection Enhancement Request Number 129 donnte@microsoft.com Bug in XBDd3 (rdvk# 176) [DT-XBD-80] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: no action required _____________________________________________________________________________ Page: 228 Line: 7594 Section: 11.1.7 Problem: Is the ambiguity about precedence something that can now be resolved? Action: I move that this be discussed and if possible a decision made to remove this ambiguity. _____________________________________________________________________________ Comment Enhancement Request Number 130 donnte@microsoft.com Bug in XBDd3 (rdvk# 175) [DT-XBD-79] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 228 Line: 7625 Section: 11.1.7 Problem: "In this case" repeated too often, becomes confusing. Action: The "in this case" on lines 7621 and 7623 should be "in case C". However the one at 7625 means something else: "If bytes are not received...". Change. Consider changing the "in this case"s in Case A and B to "in case [A|B]" for consistency and clarity. I don't see (but could have missed) others that don't refer to a specific case code. _____________________________________________________________________________ Objection Enhancement Request Number 131 donnte@microsoft.com Bug in XBDd3 (rdvk# 177) [DT-XBD-81] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: there will be a section in XRAT with appropriate rationale _____________________________________________________________________________ Page: 243 Line: 8197 Section: 12.2 Problem: See ERN 138 from last time. Last time, I observed that a critical piece of text was not brought forward from the original .2 rationale, and I recommended a very well defined (if large) task of bringing over EVERY bit of rationale not already included. It was rejected as "not specific". I disagree... the action was quite specific, if rather large. It's a well defined, well constrained task. And it's precisely what I meant... the rationale exists for a purpose, and dropping it when it's convenient to do so is not in anyone's best interest, because we'll repeat old mistakes that the rationale leads us away from. (I'd rather see too much go in and some deleted later than the other way around. I'd even moreso like to see careful editing so a number of the embarrassing errors I've noted below are taken care of before it gets published.) Action: Restore all .1 and .2 rationale. Specifically in this case, the text about -W being specially treated is required. (Note objections in XCU about that!) _____________________________________________________________________________ Objection Enhancement Request Number 132 donnte@microsoft.com Bug in XBDd3 (rdvk# 178) [DT-XBD-82] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 245 Line: 8205 Section: 13 Problem: "do not have to be" is not standardsese. Action: -> "need not be". _____________________________________________________________________________ editorial Enhancement Request Number 133 aj@suse.de Bug in XBDd3 (rdvk# 90) {AJ2} Sat, 29 Apr 2000 17:53:51 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 248 Line: 8301 Section: Problem: There's a typo in the sentence: "... as described " Action: Add "in" after "described": "...as described in " _____________________________________________________________________________ Objection Enhancement Request Number 134 donnte@microsoft.com Bug in XBDd3 (rdvk# 179) [DT-XBD-83] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The following shall be declared as functions or defined as macros, or both. If defined as a function, function prototypes shall... _____________________________________________________________________________ Page: 248 Line: 8305 Section: 13 Problem: As phrased, it would be possible to interpret this as allowing them to be completely omitted. ("may" would allow "neither".) (This actually applies to most man pages.) Action: The following shall be defined as either functions or macros, or both. If defined as a function, function prototypes shall... (Do everywhere.) _____________________________________________________________________________ comment Enhancement Request Number 135 ajosey@opengroup.org Bug in XBDd3 (rdvk# 96) {aj-c99-stdint} Mon, 1 May 2000 09:58:16 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A (do nothing) _____________________________________________________________________________ Page: 248 Line: 8311 Section: arpa Problem: C99 now introduces the stdint.h header, which declares sets of integer types having specified widths, and defines corresponding sets of macros. It also defines macros that specify limits of integer types corresponding to types defined in other standard headers. The inttypes.h header now includes stdint.h. This raises a question of whether occurrences of The uint32_t and uint16_t types shall be defined as described in . Should be changed to The uint32_t and uint16_t types shall be defined as described in . This applies to many places in the specifications. This aardvark is raised so this can be discussed . Action: Do nothing, leave the current references to _____________________________________________________________________________ objection Enhancement Request Number 136 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 36) [tog-c99-xbd 4] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 249 Line: 8349 Section: assert.h Problem: Change required for alignment with C99 (ref C99 section 7.2) Action: Add after line 8349: "The assert macro is redefined according to the current stat of NDEBUG each time is included." [Ed note: Add to CH The definition of the assert macro is changed for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 137 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 37) [tog-c99-xbd 5] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 249 Line: 8362 Section: complex.h Problem: Change required for alignment with C99 (ref C99 section 7.3.1-7.3.4) Action: Add the following header after line 8362: NAME complex.h - complex arithmetic SYNOPSIS #include DESCRIPTION The functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of symbols in this header. The header shall define the following constants: complex expands to _Complex. _Complex_I expands to a constant expression of type const float _Complex, with the value of the imaginary unit (that is, a number i such that i**2 = -1). imaginary expands to _Imaginary. _Imaginary_I expands to a constants expression of type const float _Imaginary with the value of the imaginary unit. I expands to either _Imaginary_I or _Complex_I. If _Imaginary_I is not defined, I expands to _Complex_I. The constants imaginary and _Imaginary_I are only defined if the implementation supports imaginary types. A program may undefine and then, perhaps, redefine complex, imaginary and I. The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided for use with an ISO C standard compiler. double complex cacos(double complex); float complex cacosf(float complex); long double complex cacosl(long douple complex); double complex casin(double complex); float complex casinf(float complex); long double complex casinl(long double complex); double complex catan(double complex); float complex catanf(float complex); long double complex catanl(long double complex); double complex ccos(double complex); float complex ccosf(float complex); long double complex ccosl(long double complex); double complex csin(double complex); float complex csinf(float complex); long double complex csinl(long double complex); double complex ctan(double complex); float complex ctanf(float complex); long double complex ctanl(long double complex); double complex cacosh(double complex); float complex cacoshf(float complex); long double complex cacoshl(long double complex); double complex casinh(double complex); float complex casinhf(float complex); long double complex casinhl(long double complex); double complex catanh(double complex); float complex catanhf(float complex); long double complex catanhl(long double complex); double complex ccosh(double complex); float complex ccoshf(float complex); long double complex ccoshl(long double complex); double complex csinh(double complex); float complex csinhf(float complex); long double complex csinhl(long double complex); double complex catanh(double complex); float complex catanhf(float complex); long double complex catanhl(long double complex); double complex cexp(double complex); float complex cexpf(float complex); long double complex cexpl(long double complex); double complex clog(double complex); float complex clogf(float complex); long double complex clogl(long double complex); double cabs(double complex); float cabsf(float complex); long double cabsl(long double complex); double complex cpow(double complex, double complex); float complex cpowf(float complex, float complex); long double complex cpowl(long double complex, long double complex); double complex csqrt(double complex); float complex csqrtf(float complex); long double complex csqrtl(long double complex); double carg(double complex); float cargf(float complex); long double cargl(long double complex); double cimag(double complex); float cimagf(float complex); long double cimagl(long double complex); double complex conj(double complex); float complex conjf(float complex); long double complex conjl(long double complex); double complex cproj(double complex); float complex cprojf(float complex); long double complex cprojl(long double complex); double creal(double complex); float crealf(float complex); long double creall(long double complex); APPLICATION USAGE Values are interpreted as radians, not degrees. An implementation may set errno but is not required to. Some of the complex arithmetic functions have branch cuts, across which the function is discontinuous. For implementations with a signed zero (including all IEC 60559 implementations), the sign of zero distinguishes one side of a cut from another so the function is continuous (except for format limitations) as the cut is approached from either side. For example, for the square root function, which has a branch cut along the negative real axis, the top of the cut, with imaginary part +0, maps to the positive imaginary axis, and the bottom of the cut, with imaginary part -0, maps to the negative imaginary axis. Implementations that do not support a signed zero cannot distinguish the sides of branch cuts. These implementations shall map a cut so the function is continuous as the cut is approached coming around the finite endpoint of the cut in a counter clockwise direction. (Branch cuts for the functions specified here have just one finite endpoint.) For example, for the square root function, coming counter clockwise around the finite endpoint of the cut along the negative real axis approaches the cut from above, so the cut maps to the positive imaginary axis. The usual mathematical formulas for complex multiply, divide, and absolute value are problematic because of their treatment of infinities and because of undue overflow and underflow. The CX_LIMITED_RANGE pragma can be used to inform the implementation that (where the state is on) the usual mathematical formulas are acceptable. The pragma can occur either outside external declarations or preceding all explicit declarations and statements inside a compound statement. When outside external declarations, the pragma takes effect from its occurrence until another CX_LIMITED_RANGE pragma is encountered, or until the end of the translation unit. When inside a compound statement, the pragma takes effect from its occurrence until another CX_LIMITED_RANGE pragma is encountered (including within a nested compound statement), or until the end of the compound statement; at the end of a compound statement the state for the pragma is restored to its condition just before the compound statement. If this pragma is used in any other context, the behavior is undefined. The default state for the pragma is off. RATIONALE The choice of I instead of i for the imaginary unit concedes to the widespread use of the identifier i for other purposes. The programmer can use a different identifier, say j, for the imaginary unit by following the inclusion of with #undef I #define j _Imaginary_I 35 An I suffix to designate imaginary constants is not required, as multiplication by I provides a sufficiently convenient and more generally useful notation for imaginary terms. The corresponding real type for the imaginary unit is float so that use of I for algorithmic or 40 notational convenience will not result in widening types. On systems with imaginary types, the programmer has the ability to control whether use of the macro I introduces an imaginary type, by explicitly defining I to be _Imaginary_I or _Complex_I. Disallowing imaginary types is useful for some programs intended to run on 45 implementations without support for such types. The macro _Imaginary_I provides a test for whether imaginary types are supported The cis function (cos(x) + I*sin(x)) was considered but rejected because its implementation is easy and straightforward, even though some implementations could compute sine and cosine more efficiently in tandem. FUTURE DIRECTIONS The function names cerf cerfc cexp2 cexpm1 clog10 clog1p clog2 clgamma ctgamma and the same names suffixed with f or l may be added to the declarations in the header. SEE ALSO The System Interfaces volume of IEEE Std. 1003.1-200x, cacos(), casin(), catan(), ccos(), csin(), ctan(), cacosh(), casinh(), catanh(), ccosh(), csinh(), ctanh(), cexp(), clog(), cabs(), cpow(), csqrt(), carg(), cimag(), conj(), cproj(), creal(). CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 138 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 39) [tog-c99-xbd 7] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 252 Line: 8424 Section: ctype.h Problem: Change required for alignment with C99 (ref C99 section 7.4.1.3). Action: Add "int isblank(int); [Ed note: Add to CH The isblank() function is added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Editorial Enhancement Request Number 139 donnte@microsoft.com Bug in XBDd3 (rdvk# 180) [DT-XBD-84] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 255 Line: 8502 Section: dirent Problem: Is this paragraph still relevant? Action: Make case for retaining, or delete. _____________________________________________________________________________ objection Enhancement Request Number 140 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 38) [tog-c99-xbd 6] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 257 Line: 6565 Section: errno.h Problem: Change required for alignment with C99 (ref C99 section 7.5). Action: Change "All the error numbers apart from [EDOM] and [ERANGE] are extensions to the ISO C standard ..." To "All the error numbers apart from [EDOM], [ERANGE] and [EILSEQ] are extensions to the ISO C standard ..." _____________________________________________________________________________ objection Enhancement Request Number 141 prindle@voicenet.com Bug in XBDd3 (rdvk# 202) [prindle.xbd-6] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: file an interp. Add reviewers note with the problem/action statement below and noting that an interp may be filed. _____________________________________________________________________________ Page: 262 Line: 8755,8767,8791 Section: Problem: The function posix_madvise() is misplaced in . It should be prototyped in header as shown on the synopsis page for that function. Action: Remove posix_madvise() from these 3 lines (and any others you may find in this header), and put it instead into the equivalent places in . If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision (SSWG-RT will immediately recommend the fix as part of the interpretation, because as it stands the .1d standard is internally inconsistent). ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 142 donnte@microsoft.com Bug in XBDd3 (rdvk# 181) [DT-XBD-85] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 264 Line: 8815 Section: float Problem: Wrong word. Action: "constant" -> "constants". _____________________________________________________________________________ objection Enhancement Request Number 143 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 34) [tog-c99-xbd 2] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 264 Line: 8824 Section: float.h Problem: Change required for alignment with C99 (ref C99 section 5.2.4.2.2) Action: Add after line 8824: The values of operations with floating operands and values subject to the usual arithmetic conversions and of floating constants are evaluated to a format whose range and precision may be greater than required by the type. The use of evaluation formats is characterized by the implementation-dependent value of FLT_EVAL_METHOD: -1 indeterminable; 0 evaluate all operations and constants just to the range and precision of the type; 1 evaluate operations and constants of type float and double to the range and precision of the double type, evaluate long double operations and constants to the range and precision of the long double type; 2 evaluate all operations and constants to the range and precision of the long double type. All other negative values for FLT_EVAL_METHOD characterize implementation-dependent behavior. [Ed note: Add to CH The description of the operations with floating point values is updated for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ Objection Enhancement Request Number 144 donnte@microsoft.com Bug in XBDd3 (rdvk# 182) [DT-XBD-86] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: these are not spec'd in C99. Add a dagger and footnote to show that these are imp-defined values. _____________________________________________________________________________ Page: 264 Line: 8826 Section: float Problem: (This was left open last time, and I see no resolution.) What if value is omitted (in 2 cells on the next page)? (In particular, what is its sign?) Action: Actually, the easy way out of this is to put -1 and 1 into the Value column in the blank slots on the next page. _____________________________________________________________________________ objection Enhancement Request Number 145 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 40) [tog-c99-xbd 8] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 265 Line: 8792 Section: fenv.h Problem: Change required for alignment with C99 (ref C99 section 7.6-7.6.1). Action: Add the following header after line 8792: NAME fenv.h - floating-point environment SYNOPSIS #include DESCRIPTION The functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of symbols in this header. The header shall define the following data types through typedef: fenv_t which represents the entire floating-point environment. The floating-point environment refers collectively to any floating-point status flags and control modes supported by the implementation. fexcept_t represents the floating-point status flags collectively, including any status the implementation associates with the flags. A floating-point status flag is a system variable whose value is set (but never cleared) when a floating-point exception is raised, which occurs as a side effect of exceptional floating-point arithmetic to provide auxiliary information. A floating-point control mode is a system variable whose value may be set by the user to affect the subsequent behavior of floating-point arithmetic. The header shall define the following constants: FE_DIVBYZERO ) These constants are defined if and only if the FE_INEXACT ) implementation supports the floating-point FE_INVALID ) exception by means of the flaoting-point FE_OVERFLOW ) functions fwclearexcept(), fegetexceptflag(), FE_UNDERFLOW ) feraiseexcept(), fesetexceptflag and ) fetestexcept. Each expands to an integer ) constant expression with values such that ) bitwise ORs of all combinations of the ) constants result in distinct values. FE_ALL_EXCEPT is simply the bitwise OR of all floating-point exception constants defined above. FE_DOWNWARD ) These constants are defined is and only if the FE_TONEAREST ) supports getting and setting the represented FE_TOWARDZERO ) rounding direction by means of the fegetround() FE_UPWARD ) and fesetround() functions. Each expands to an ) integer constant expression whose values are ) distinct non-negative vales. FE_DFL_ENV represents the floating-point environment (that is, the one installed at program startup) and has type "pointer to const-qualified fenv_t). It can be used as an argument to functions that manage the floating-point environment. The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided for use with an ISO C standard compiler. void feclearexcept(int); void fegetexceptflag(fexcept_t, int); void feraiseexcept(int); void fesetexceptflag(const fexcept_t, int); int fetestexcept(int); int fegetround(void); int fesetround(int); void fegetenv(fenv_t); int feholdexcept(fenv_t); void fesetenv(const fenv_t); void feupdateenv(const fenv_t); APPLICATION USAGE This header is designed to support the floating-point exception status flags and directed-rounding control modes required by IEC 60559, and other similar floating-point state information. Also it is designed to facilitate code portability among all systems. Certain programming conventions support the intended model of use for the floating-point environment: * a function call does not alter its caller's floating-point control modes, clear its caller's floating-point status flags, nor depend on the state of its caller's floating-point status flags unless the function is so documented; * a function call is assumed to require default floating-point control modes, unless stated otherwise in the system documentation; * a function call is assumed to have the potential for raising floating-point exceptions, unless stated otherwise in the system documentation. With these conventions, a programmer can safely assume default floating-point control modes (or be unaware of them). The responsibilities associated with accessing the floating-point environment fall on the programmer or program that does so explicitly. Even though the rounding direction macros may expand to constants corresponding to the values of FLT_ROUNDS, they are not required to do so. The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes. The pragma shall occur either outside external declarations or preceding all explicit declarations and statements inside a compound statement. When outside external declarations, the pragma takes effect from its occurrence until another FENV_ACCESS pragma is encountered, or until the end of the translation unit. When inside a compound statement, the pragma takes effect from its occurrence until another FENV_ACCESS pragma is encountered (including within a nested compound statement), or until the end of the compound statement; at the end of a compound statement the state for the pragma is restored to its condition just before the compound statement. If this pragma is used in any other context, the behavior is undefined. If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma off, the behavior is undefined. The default state (on or off) for the pragma is implementation-dependent. (When execution passes from a part of the program translated with FENV_ACCESS off to a part translated with FENV_ACCESS on, the state of the floating-point status flags is unspecified and the floating-point control modes have their default settings.) For example: #include void f(double x) { #pragma STDC FENV_ACCESS ON void g(double); void h(double); /* ... */ g(x + 1); h(x + 1); /* ... */ } If the function g might depend on status flags set as a side effect of the first x + 1, or if the second x + 1 might depend on control modes set as a side effect of the call to function g, then the program shall contain an appropriately placed invocation of #pragma STDC FENV_ACCESS ON. RATIONALE The floating-point environment as defined here includes only execution-time modes, not the myriad of possible translation-time options that can affect a program's results. Each such option's deviation from the C Standard should be well documented. Dynamic vs. static modes Dynamic modes are potentially problematic because 1. the programmer may have to defend against undesirable mode settings, which imposes intellectual as well as time and space overhead. 2. the translator may not know which mode settings will be in effect or which functions change them at execution time, which inhibits optimization. C9X addresses these problems without changing the dynamic nature of the modes. An alternate approach would have been to present a model of static modes with explicit utterances to the translator about what mode settings would be in effect. This would have avoided any uncertainty due to the global nature of dynamic modes or the dependency on unenforced conventions. However, some essentially dynamic mechanism still would have been needed in order to allow functions to inherit (honor) their caller's modes. The IEC 60559 standard requires dynamic rounding direction modes. For the many architectures that maintain these modes in control registers, implementation of the static model would be more costly. Also, standard C has no facility, other than pragmas, for supporting static modes. An implementation on an architecture that provides only static control of modes, for example through opword encodings, still could support the dynamic model, by generating multiple code streams with tests of a private global variable containing the mode setting. Only modules under an enabling FENV_ACCESS pragma would need such special treatment. Translation An implementation is not required to provide a facility for altering the modes for translation-time arithmetic, or for making exception flags from the translation available to the executing program. The language and library provide facilities to cause floating-point operations to be done at execution time when they can be subjected to varying dynamic modes and their exceptions detected. The need does not seem sufficient to require similar facilities for translation. The fexcept_t type fexcept_t does not have to be an integer type. Its values must be obtained by a call to fegetexceptflag, and cannot be created by logical operations from the exception macros. An implementation might simply implement fexcept_t as an int and use the representations reflected by the exception macros, but isnt required to: other representations might contain extra information about the exceptions. fexcept_t might be a struct with a member for each exception (that might hold the address of the first or last floating-point instruction that caused that exception). C9X makes no claims about the internals of an fexcept_t, and so the user cannot inspect it. Exception and rounding macros Unsupported macros are not defined in order to assure that their use results in a translation error. A program might explicitly define such macros to allow translation of code (perhaps never executed) containing the macros. An unsupported exception macro should be defined to be 0, for example #ifndef FE_INEXACT #define FE_INEXACT 0 #endif so that a bitwise OR of macros has a reasonable effect. Exceptions In previous drafts of the C Standard , several of the exception functions returned an int indicating whether the excepts argument represented supported exceptions. This facility was deemed unnecessary because excepts & ~FE_ALL_EXCEPT can be used to test invalidity of the excepts argument. Rounding precision The IEC 60559 floating-point standard prescribes rounding precision modes (in addition to the rounding direction modes covered by the functions in this section) as a means for systems whose results are always double or extended to mimic systems that deliver results to narrower formats. An implementation of C can meet this goal in any of the following ways: 1. By supporting the evaluation method indicated by FLT_EVAL_METHOD equal to 0. 2. By providing pragmas or compile options to shorten results by rounding to IEC 60559 single or double precision. 3. By providing functions to dynamically set and get rounding precision modes which shorten results by rounding to IEC 60559 single or double precision. Recommended are functions fesetprec and fegetprec and macros FE_FLTPREC, FE_DBLPREC, and FE_LDBLPREC, analogous to the functions and macros for the rounding direction modes. The C Standard does not include a portable interface for precision control because the IEC 60559 floating-point standard is ambivalent on whether it intends for precision control to be dynamic (like the rounding direction modes) or static. Indeed, some floating-point architectures provide control modes suitable for a dynamic mechanism, and others rely on instructions to deliver single- and double-format results suitable only for a static mechanism. FUTURE DIRECTIONS None. SEE ALSO The System Interfaces volume of IEEE Std. 1003.1-200x, feclearexcept(), fegetexceptflag(), feraiseexcept(), fesetexceptflag(), fetestexcept(), fegetround(), fesetround(), fegetenv(), feholdexcept(), fesetenv(), feupdateenv(). CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 146 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 35) [tog-c99-xbd 3] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 265 Line: 8827 Section: float.h Problem: Change required for alignment with C99 (ref C99 section 5.2.4.2.2) Action: Insert the following into the table starting on line 8827 (after the section ending with LDBL_MANT_DIG): DECIMAL_DIG number of decimal digits, n, such that any 10 floating-point number in the widest supported floating type with pmax radix b digits can be rounded to a floating-point number with n decimal digits and back again without change to the value, [equation from C99 page 25] _____________________________________________________________________________ comment Enhancement Request Number 147 ajosey@opengroup.org Bug in XBDd3 (rdvk# 5) {aj-22300-1} Wed, 22 Mar 2000 12:54:33 GMT _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Mark as (Legacy) on line 8912 Add to change history after 8927 The constant FNM_NOSYS is marked Legacy _____________________________________________________________________________ Page: 269 Line: 8912 Section: fnmatch.h Problem: The symbol FNM_NOSYS is described as for implementations that do not support this function. Since this is a required function should we drop the requirement for the implementation to support the symbol? Action: Delete line 8912 Add to change history after 8927 The constant FNM_NOSYS is no longer required. _____________________________________________________________________________ objection Enhancement Request Number 148 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 41) [tog-c99-xbd 9] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add after line 9114: The header shall include the header . Add a reviewers note asking reviewers to propose changes to eliminate duplication between inttypes.h and stdint.h _____________________________________________________________________________ Page: 277 Line: 9114 Section: inttypes.h Problem: Change required for alignment with C99 (ref C99 section 7.8). Action: Add after line 9114: The header shall include the header and may extend it with additional facilities provided by host implementations. _____________________________________________________________________________ objection Enhancement Request Number 149 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 42) [tog-c99-xbd 10] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9115 Section: inttypes.h Problem: Change required for alignment with C99 (ref C99 section 7.8). Action: Add after line 9115: imaxdiv_t Structure type that is the type of the value returned by the imaxdiv() function. _____________________________________________________________________________ comment Enhancement Request Number 150 ajosey@opengroup.org Bug in XBDd3 (rdvk# 94) {c99-inttypes.h} Sun, 30 Apr 2000 09:01:07 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take action, but thee macros associated with c89 should be removed, not just marked legacy _____________________________________________________________________________ Page: 277 Line: 9125 Section: inttypes.h Problem: As part of the introduction of the new c99 utility, we need to mark obsolete (LEGACY) the macros associated with the data models used by c89 , and introduce new macros for the data models used by c99. This page has some examples using the c89 macros. Action: At a minimum change to their new c99 equivalents, i.e. change occurrences of "XBS5" and "XBS" to "POSIX_V6" _____________________________________________________________________________ objection Enhancement Request Number 151 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 43) [tog-c99-xdb 11] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9134 Section: inttypes.h Problem: Change required for alignment with C99 (ref C99 section 7.8). Action: Add after line 9134: If __STDC_FORMAT_MACROS is defined before is included, then the following object-like macros shall be defined. Each expands to a character string literal containing a conversion specifier, possibly modified by a length modifier, suitable for use within the format argument of a formatted input/output function when converting the corresponding integer type. These macro names have the general form of PRI (character string literals for the fprintf and fwprintf family) or SCN (character string literals for the fscanf and fwscanf family), followed by the conversion specifier, followed by a name corresponding to a similar type name in . In these names, N represents the width of the type as described in . For example, PRIdFAST32 can be used in a format string to print the value of an integer of type int_fast32_t. The fprintf macros for signed integers are: PRIdN PRIdLEASTN PRIdFASTN PRIdMAX PRIdPTR PRIiN PRIiLEASTN PRIiFASTN PRIiMAX PRIiPTR The fprintf macros for unsigned integers are: PRIoN PRIoLEASTN PRIoFASTN PRIoMAX PRIoPTR PRIuN PRIuLEASTN PRIuFASTN PRIuMAX PRIuPTR PRIxN PRIxLEASTN PRIxFASTN PRIxMAX PRIxPTR PRIXN PRIXLEASTN PRIXFASTN PRIXMAX PRIXPTR The fscanf macros for signed integers are: SCNdN SCNdLEASTN SCNdFASTN SCNdMAX SCNdPTR SCNiN SCNiLEASTN SCNiFASTN SCNiMAX SCNiPTR The fscanf macros for unsigned integers are: SCNoN SCNoLEASTN SCNoFASTN SCNoMAX SCNoPTR SCNuN SCNuLEASTN SCNuFASTN SCNuMAX SCNuPTR SCNxN SCNxLEASTN SCNxFASTN SCNxMAX SCNxPTR For each type that the implementation provides in , the corresponding fprintf macros shall be defined and the corresponding fscanf macros shall be defined unless the implementation does not have a suitable fscanf length modifier for the type. The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided for use with an ISO C standard compiler. intmax_t imaxabs(intmax_t); imaxdiv_t imaxdiv(intmax_t, intmax_t); intmax_t strtoimax(const char * restrict, char ** restrict, int); uintmax_t strtoumax(const char * restrict, char ** restrict, int); intmax_t wcstoimax(const wchar_t * restrict, wchar_t ** restrict, int); uintmax_t wcstoumax(const wchar_t * restrict, wchar_t ** restrict, int); EXAMPLE #include #include int main(void) { uintmax_t i = UINTMAX_MAX; // this type always exists wprintf(L"The largest integer value is %020" PRIxMAX "\n", i); return 0; } _____________________________________________________________________________ objection Enhancement Request Number 152 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 44) [tog-c99-xdb 11a] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9137 Section: inttypes.h Problem: Change required for alignment with C99 (ref C99 section 7.8). Action: Change "None." To " was derived from the header of the same name found on several existing 64-bit systems. The C Standard Committee debated other methods for specifying integer sizes and other characteristics, but in the end decided to standardize existing practice rather than innovate in this area. C89 specifies that the language should support four signed and unsigned integer data types, char, short, int and long, but places very little requirement on their size other than that int and short be at least 16 bits and long be at least as long as int and not smaller than 32 bits. For 16-bit systems, most implementations assign 8, 16, 16 and 32 bits to char, short, int, and long, respectively. For 32-bit systems, the common practice is to assign 8, 16, 32 and 32 bits to these types. This difference in int size can create some problems for users who migrate from one system to another which assigns different sizes to integer types, because Standard Cs integer promotion rule can produce silent changes unexpectedly. The need for defining an extended integer type increased with the introduction of 64-bit systems. The purpose of is to provide a set of integer types whose definitions are consistent across machines and independent of operating systems and other implementation idiosyncrasies. It defines, via typedef, integer types of various sizes. Implementations are free to typedef them as Standard C integer types or extensions that they support. Consistent use of this header will greatly increase the portability of a users program across platforms." _____________________________________________________________________________ objection Enhancement Request Number 153 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 45) [tog-c99-xdb 11b] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9140 Section: inttypes.h Problem: Change required for alignment with C99 (ref C99 section 7.8). Action: Change "None." To "Macro names beginning with PRI or SCN followed by any lowercase letter or X may be added to the macros defined in the header." _____________________________________________________________________________ Objection Enhancement Request Number 154 donnte@microsoft.com Bug in XBDd3 (rdvk# 183) [DT-XBD-87] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change line 9551 to "Value" instead of "Maximum Value". And add the change to the end of the para suggested at line 9339 _____________________________________________________________________________ Page: 288 Line: 9549 Section: limits Problem: (This was left open last time, and I see no resolution.) When discussing _POSIX_CLOCKRES_MIN: See line 9339, that implies that constants ending in _MIN are negative. Action: Change 9339: "The items in the list ending in _MIN, and referring to negative constants...". At the end of the paragraph add "For positive constants ending in _MIN, this indicates the minimum acceptable value.". _____________________________________________________________________________ objection Enhancement Request Number 155 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 46) [tog-c99-xdb 12] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 297 Line: 9913 Section: locale.h Problem: Change required for alignment with C99 (ref C99 section 7.11). Action: Add after line 9913: char int_n_cs_precedes; char int_n_sep_by_space char int_n_sign_posn char int_p_cs_precedes char int_p_sep_by_space char int_p_sign_posn [Ed note: Add to CH The lconv structure is expanded with new members, int_n_cs_precedes, int_n_sep_by_space, int_n_sign_posn int_p_cs_precedes, int_p_sep_by_space, and int_p_sign_posn for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 156 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 48) [tog-c99-xdb 14] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9968 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Add after line 9968: The header shall include definitions for at least the following types: float_t A floating type at least as wide as float. double_t A floating type at least as wide as double, and at least as wide as float_t. If FLT_EVAL_METHOD equals 0, float_t and double_t shall be float and double, respectively; if FLT_EVAL_METHOD equals 1, they shall both be double; if FLT_EVAL_METHOD equals 2, they shall both be long double; for other values of FLT_EVAL_METHOD, they are otherwise implementation-dependent. [Ed note: Add to CH The types float_t and double_t are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 157 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 47) [tog-c99-xdb 13] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9968 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Add after line 9968: The header shall define the following macros, where real-floating indicates that the argument shall be an expression of real floating type: int fpclassify(real-floating x); int isfinite(real-floating x); int isinf(real-floating x); int isnan(real-floating x); int isnormal(real-floating x); int signbit(real-floating x); int isgreater(real-floating x, real-floating y); int isgreaterequal(real-floating x, real-floating y); int isless(real-floating x, real-floating y); int islessequal(real-floating x, real-floating y); int islessgreater(real-floating x, real-floating y); int isunordered(real-floating x, real-floating y); [Ed note: Add to CH The macros fpclassify(), isfinite(), isinf(), isnan(), isnormal(), signbit(), isgreater(), isgreaterequal(), isless(), islessequal(), islessgreater(), isunordered(), are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 158 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 49) [tog-c99-xdb 15] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299 Line: 9988 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Add after line 9988: HUGE_VALF A positive float constant expression. Used as an error value returned by the mathematics library. HUGE_VALF evaluates to +infinity on systems supporting the IEEE Std. 754: 1985 standard. HUGE_VALD A positive long double constant expression. Used as an error value returned by the mathematics library. HUGE_VALD evaluates to +infinity on systems supporting the IEEE Std. 754: 1985 standard. INFINITY A constant expression of type float representing positive or unsigned infinity, if available; else a positive constant of type float that overflows at translation time. NAN A constant expression of type float representing a quiet NaN. This symbolic constant is only defined if the implementation supports quiet NaNs for the float type. The following macros shall be defined for number classification. They represent the mutually exclusive kinds of floating-point values. They expand to integer constant expressions with distinct values. Additional implementation-dependent floating-point classifications, with macro definitions beginning with FP_ and an uppercase letter, may also be specified by the implementation. FP_INFINITE FP_NAN FP_NORMAL FP_SUBNORMAL FP_ZERO The following macros are optional. If FP_FATS_FMA is defined, it shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. FP_FAST_FMA FP_FAST_FMAF FP_FAST_FMAL FP_FAST_FMAF and FP_FAST_FMAL are, respectively, float and long double analogs of FP_FAST_FMA. The following macros shall expand to integer constant expressions whose values are returned by ilogb(x) if x is zero or NaN, respectively. The value of FP_ILOGB0 shall be either INT_MIN or -INT_MAX. The value of FP_ILOGBNAN shall be either INT_MAX or INT_MIN. FP_ILOGB0 FP_ILOGBNAN The following macros shall expand to the integer constants 1 and 2, respectively; MATH_ERRNO MATH_ERREXCEPT The following macro shall expand to an expression that has type int and the value MATH_ERRNO, MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling is constant for the duration of the program. It is unspecified whether math_errhandling is a macro or an identifier with external linkage. If a macro definition is suppressed or a program defines an identifier with the name math_errhandling, the behavior is undefined. If the expression math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation shall define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in . math_errhandling _____________________________________________________________________________ objection Enhancement Request Number 159 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 50) [tog-c99-xdb 16] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 299-300 Line: 9991-10035 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Add the following prototypes to the list on lines 9991-10035: float acosf(float); float acoshf(float); long double acoshl(long double); long double acosl(long double); float asinf(float); float asinhf(float); long double asinhl(long double); long double asinl(long double); float atan2f(float, float); long double atan2l(long double, long double); float atanf(float); float atanhf(float); long double atanhl(long double); long double atanl(long double); double cbrt(double); float cbrtf(float); long double cbrtl(long double); float ceilf(float); long double ceill(long double); double copysign(double, double); float copysignf(float, float); long double copysignl(long double, long double); float cosf(float); float coshf(float); long double coshl(long double); long double cosl(long double); float erfcf(float); long double erfcl(long double); float erff(float); long double erfl(long double); double exp2(double); float exp2f(float); long double exp2l(long double); float expf(float); long double expl(long double); float expm1f(float); long double expm1l(long double); float fabsf(float); long double fabsl(long double); double fdim(double, double); float fdimf(float, float); long double fdiml(long double, long double); float floorf(float); long double floorl(long double); double fma(double, double, double); float fmaf(float, float, float); long double fmal(long double, long double, long double); double fmax(double, double); float fmaxf(float, float); long double fmaxl(long double, long double); double fmin(double, double); float fminf(float, float); long double fminl(long double, long double); float fmodf(float, float); long double fmodl(long double, long double); float frexpf(float value, int *); long double frexpl(long double value, int *); float hypotf(float, float); long double hypotl(long double, long double); int ilogbf(float); int ilogbl(long double); long int lrint(double); long int lrintf(float); long int lrintl(long double); long int lround(double); long int lroundf(float); long int lroundl(long double); float ldexpf(float, int); long double ldexpl(long double, int); float lgammaf(float); long double lgammal(long double); float log10f(float); long double log10l(long double); float log1pf(float); long double log1pl(long double); double log2(double); float log2f(float); long double log2l(long double); float logbf(float); long double logbl(long double); float logf(float); long double logl(long double); long long int llrint(double); long long int llrintf(float); long long int llrintl(long double); long long int llround(double); long long int llroundf(float); long long int llroundl(long double); float modff(float, float *); long double modfl(long double, long double *); double nan(const char *); float nanf(const char *); long double nanl(const char *); double nearbyint(double); float nearbyintf(float); long double nearbyintl(long double); float nextafterf(float, float); long double nextafterl(long double, long double); double nexttoward(double, long double); float nexttowardf(float, long double); long double nexttowardl(long double, long double); float powf(float, float); long double powl(long double, long double); float remainderf(float, float); long double remainderl(long double, long double); double remquo(double, double, int *); float remquof(float, float, int *); long double remquol(long double, long double, int *); float rintf(float); long double rintl(long double); double round(double); float roundf(float); long double roundl(long double); double scalbln(double, long int); float scalblnf(float, long int); long double scalblnl(long double, long int); double scalbn(double, int); float scalbnf(float, int); long double scalbnl(long double, int); float sinf(float); float sinhf(float); long double sinhl(long double); long double sinl(long double); float sqrtf(float); long double sqrtl(long double); float tanf(float); float tanhf(float); long double tanhl(long double); long double tanl(long double); double tgamma(double); float tgammaf(float); long double tgammal(long double); double trunc(double); float truncf(float); long double truncl(long double); _____________________________________________________________________________ objection Enhancement Request Number 160 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 51) [tog-c99-xdb 17] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 300 Line: 10041 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Change line 10041 to: The FP_CONTRACT pragma can be used to allow (if the state is on) or disallow (if the state is off) the implementation to contract expressions (6.5). Each pragma can occur either outside external declarations or preceding all explicit declarations and statements inside a compound statement. When outside external declarations, the pragma takes effect from its occurrence until another FP_CONTRACT pragma is encountered, or until the end of the translation unit. When inside a compound statement, the pragma takes effect from its occurrence until another FP_CONTRACT pragma is encountered (including within a nested compound statement), or until the end of the compound statement; at the end of a compound statement the state for the pragma is restored to its condition just before the compound statement. If this pragma is used in any other context, the behavior is undefined. The default state (on or off) for the pragma is implementation-dependent. _____________________________________________________________________________ objection Enhancement Request Number 161 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 52) [tog-c99-xdb 17a] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 300 Line: 10042 Section: math.h Problem: Change required for alignment with C99 (ref C99 section 7.12). Action: Change "None." To "Before C9X, the math library was defined only for the floating type double. All the names formed by appending f or l to a name in were reserved to allow for the definition of float and long double libraries; and C9X provides for all three versions of math functions. The functions ecvt, fcvt, and gcvt have been dropped from the C Standard since their capability is available through sprintf. These are provided on XSI-Conformant systems supporting the Legacy Option Group." _____________________________________________________________________________ Objection Enhancement Request Number 162 donnte@microsoft.com Bug in XBDd3 (rdvk# 184) [DT-XBD-88] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 303 Line: 10095 Section: mqueue Problem: The business about using a file descriptor doesn't belong here (in the header description) but rather with the function description (if it's not already there). Action: Move "A message queue descriptor..." to XSH, line 23707. _____________________________________________________________________________ objection Enhancement Request Number 163 prindle@voicenet.com Bug in XBDd3 (rdvk# 201) [prindle.xbd-5] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add reviewers note explaining problem and probable solution. _____________________________________________________________________________ Page: 303 Line: 10115 Section: Problem: The return type from mq_timedreceive() should be ssize_t, not int. See [prindle.xsh-2] for an explanation. Action: Change first "int" to "ssize_t". If deemed necessary, file a POSIX interpretation request to place this change into the scope of the .1 revision (SSWG-RT will immediately recommend the fix as part of the interpretation, because as it stands the .1d standard is inconsistent with .1 mq_receive()). ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 164 drepper@redhat.com Bug in XBDd3 (rdvk# 80) {ud-44} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Perform the action below, but remove the "int" in "unsigned int" _____________________________________________________________________________ Page: 306 Line: 10185-10186 Section: Problem: The type names in the definition of the members of struct if_nameindex appear after the names. Other definitions throughout the document have type and name in the other order. Action: Change lines 10185 and 10186 to: unsigned int if_index Numeric index of the interface. char *if_name Null-terminated names of the interface. _____________________________________________________________________________ comment Enhancement Request Number 165 drepper@redhat.com Bug in XBDd3 (rdvk# 82) {ud-46} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: this was deliberate, and part of an earlier compromise between "int" and "socklen_t" (where socklen_t is a long, which may be 64 bits, while an int is 32 bits) _____________________________________________________________________________ Page: 307 Line: 10221 Section: Problem: The h_length member of struct hostent currently is defined as having type int. This is inconsistent with the rest of the specification where the values of this kind (length of an address) is specified using socklen_t. Action: Replace line 10221 with: socklen_t h_length The length, in bytes, of the address. _____________________________________________________________________________ comment Enhancement Request Number 166 drepper@redhat.com Bug in XBDd3 (rdvk# 81) {ud-45} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 308 Line: 10277,10280 Section: Problem: The currently contains the prototypes struct hostent *gethostbyaddr (const void *, socket_t, int) struct hostent *getipnodebyaddr (const void *, socket_t, int, int*) The type socket_t is nowhere defined as far as I can say. From the context I would guess that this actually should be socklen_t. Also, there is no reference to where socklen_t is defined, which is needed in struct addrinfo. Action: Replace socket_t in lines 10277 and 10280 by socklen_t. Add as line 10295 the paragraph: The type socklen_t shall by defined through typedef as described in . _____________________________________________________________________________ comment Enhancement Request Number 167 drepper@redhat.com Bug in XBDd3 (rdvk# 18) {ud-21} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 308 Line: 10277 Section: Problem: is missing the prototype for gai_strerror. (I should have seen this before sending ud-20.) Action: Add as line 10277: char *gai_strerror (int ecode); _____________________________________________________________________________ comment Enhancement Request Number 168 drepper@redhat.com Bug in XBDd3 (rdvk# 19) {ud-20} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 308 Line: 10277 Section: Problem: is missing the prototype for getaddrinfo. At least I think this is the right header. The getaddinfo description in XSH also mentioned sys/socket.h but there is also no trace of getaddrinfo. The same is true for freeaddrinfo. Action: Add as line 10276: void freeaddrinfo (struct addrinfo *ai); Add as line 10277: int getaddrinfo (const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res); _____________________________________________________________________________ comment Enhancement Request Number 169 drepper@redhat.com Bug in XBDd3 (rdvk# 20) {ud-22} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 308 Line: 10282 Section: Problem: And number three: is missing the prototype for getnameinfo. Action: Add as line 10282: int getnameinfo(const struct sockaddr *sa, socklen_t salen, char *node, socklen_t nodelen, char *service, socklen_t servicelen, unsigned int flags); _____________________________________________________________________________ comment Enhancement Request Number 170 drepper@redhat.com Bug in XBDd3 (rdvk# 22) {ud-24} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10359 Section: Problem: The definition of uint32_t should be required as it is needed in struct sockaddr_in6. Probably the inclusion of inttypes.h should be allowed. Action: Add new line before line 10359: The uint32_t type shall be defined as described in . Inclusion of the header may also make visible all symbols from . _____________________________________________________________________________ editorial Enhancement Request Number 171 drepper@redhat.com Bug in XBDd3 (rdvk# 83) {ud-47} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10370-10372 Section: Problem: The structure in6_addr is introduced in a different way than, e.g., in_addr. Instead of defining the members of the struct in a list they are described in words which is IMO less readable and also brings up the question why this is done differently. There is no reason for that and therefore I suggest to unify this. Action: Replace the paragraph in lines 10370-10372 with: The header shall define the in6_addr structure that contains at least the following member: uint8_t s6_addr[16] This array is used to contain a 128-bit IPv6 address, stored in the network byte order. _____________________________________________________________________________ editorial Enhancement Request Number 172 ajosey@opengroup.org Bug in XBDd3 (rdvk# 14) {aj-netinet.h-1} Tue, 4 Apr 2000 13:28:00 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10375-10379 Section: netinet Problem: The transcription from the XNS5.2 has the member and types in the wrong order for the standard header layout. Action: Change(reorder) text within 10375-10379 to sa_family_t sin6_family AF_INET6. in_port_t sin6_port Port number. uint32_t sin6_flowinfo IPv6 traffic class and flow information. struct in6_addr sin6_addr IPv6 address. uint32_t sin6_scope_id Set of interfaces for a scope. _____________________________________________________________________________ editorial Enhancement Request Number 173 drepper@redhat.com Bug in XBDd3 (rdvk# 84) {ud-48} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10387-10389 Section: Problem: Two comments about the paragraph in lines 10386 to 10389: - the variable in6addr_any is desribed in textual form which is less readable than the use of the C syntax - IN6ADDR_ANY_INIT is described as a constant. This is not possible. They value is normally something like { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 } } which is not a constant. I would propose to use "macro" instead of "symbolic constant" and also mention it has to be constant at compile time. Action: Replace the paragraph in lines 10386 to 10389 with: The header shall declare the following external variable: struct in6_addr in6addr_any This variable is initilized by the system to contain the wildcard IPv6 address. The header also defines the following macro: IN6ADDR_ANY_INIT This macro must be constant at compile time and can be used to initialize a variable of type struct in6_addr to the IPv6 wildcard address. _____________________________________________________________________________ editorial Enhancement Request Number 174 drepper@redhat.com Bug in XBDd3 (rdvk# 85) {ud-49} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 311 Line: 10390-10393 Section: Problem: Two comments about the paragraph in lines 10390 to 10393: - the variable in6addr_loopback is desribed in textual form which is less readable than the use of the C syntax - IN6ADDR_LOOPBACK_INIT is described as a constant. This is not possible. They value is normally something like { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 } } which is not a constant. I would propose to use "macro" instead of "symbolic constant" and also mention it has to be constant at compile time. Action: Replace the paragraph in lines 10390 to 10393 with: The header shall declare the following external variable: struct in6_addr in6addr_loopback This variable is initilized by the system to contain the loopback IPv6 address. The header also defines the following macro: IN6ADDR_LOOPBACK_INIT This macro must be constant at compile time and can be used to initialize a variable of type struct in6_addr to the IPv6 loopback address. _____________________________________________________________________________ editorial Enhancement Request Number 175 drepper@redhat.com Bug in XBDd3 (rdvk# 86) {ud-50} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 312 Line: 10394-10395 Section: Problem: It's a bit strange why the IPPROTO_IPV6 value is not introduced in the list with other IPPROTO_* values. Also, IPPROTO_IPV6 is required to be a symbolic constant while the others are macros. Action: Rremove paragraph 10394-10395 and add after line 10403: IPPROTO_IPV6 Internet protocol version 6. This line should be shaded with IP6 marker. _____________________________________________________________________________ comment Enhancement Request Number 176 drepper@redhat.com Bug in XBDd3 (rdvk# 21) {ud-23} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 312 Line: 10398 Section: Problem: In the desription of the ipv6_mreq structure the type names appear after the element names. This is different from normal standards. Action: Replace lines 10398 and 10399 with: struct in6_addr ipv6mr_multiaddr IPv6 multicast address. unsigned int ipv6mr_interface Interface index. _____________________________________________________________________________ editorial Enhancement Request Number 177 drepper@redhat.com Bug in XBDd3 (rdvk# 17) {ud-28} Thu, 13 Apr 2000 04:18:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 318 Line: 10576 Section: Problem: The description of PTHREAD_BARRIER_SERIAL_THREAD is missing the shading and side note BAR. Action: Shade and mark with BAR. _____________________________________________________________________________ objection Enhancement Request Number 178 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 53) [tog-c99-xdb 18] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change change marked below, but change "integral type" to integer type _____________________________________________________________________________ Page: 324 Line: 11102 Section: signal.h Problem: Change required for alignment with C99 (ref C99 section 7.14). Action: Change "sig_atomic_t Integral type of an object that can be accessed as an atomic entity, ..." To "sig_atomic_t Possibly volatile-qualified integral type of an object that can be accessed as an atomic entity, ..." _____________________________________________________________________________ editorial Enhancement Request Number 179 drepper@redhat.com Bug in XBDd3 (rdvk# 87) {ud-51} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note with problem statement/action _____________________________________________________________________________ Page: 327 Line: 10905-10906 Section: Problem: The types of the elements sched_ss_repl_period and sched_ss_init_budget are not correct. They should probably be struct timespec. Action: Replace `timespec' in lines 10905 and 10906 with `struct timespec'. _____________________________________________________________________________ editorial Enhancement Request Number 180 drepper@redhat.com Bug in XBDd3 (rdvk# 9) {ud-11} Sun, 26 Mar 2000 03:59:55 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 327 Line: 10917 Section: Problem: A new scheduler was introduced (sporadic server) but not all additions are marked appropriately. If this isn't changed old implementations are rendered automatically non-compliant because they are not prociding this definition. Action: Mark the SCHED_SPORADIC definition in gray and with the extension marker SS|TSP. _____________________________________________________________________________ editorial Enhancement Request Number 181 prindle@voicenet.com Bug in XBDd3 (rdvk# 214) [prindle.xbd-18] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_180 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 327 Line: 10917 Section: Problem: This line is dependent on one of the sporadic server options in addition to Priority Scheduling option. Action: Shade and mark SS|TSP. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 182 donnte@microsoft.com Bug in XBDd3 (rdvk# 185) [DT-XBD-89] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: although this is unusual, it has been specified this way for some time, and there is considerable hostiric practice based on using the enums as specified here. Making the specificawtio looser would not serve portability. _____________________________________________________________________________ Page: 329 Line: 10957 Section: search Problem: This overspecifies by implication. It would the the same as showing an actual struct declaration (rather than listing the members). In particular, this disallows the implementation from giving the enums specific numeric values. Action: Just list the name and members of the enum (in the same style as for a structure). _____________________________________________________________________________ Editorial Enhancement Request Number 183 donnte@microsoft.com Bug in XBDd3 (rdvk# 186) [DT-XBD-90] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 335 Line: 11138 Section: signal Problem: The Roman-number codes for default actions are very un-mnemonic, and in particular don't help assure that the table is correct. Change them to something mnemonic. Action: i -> T ii -> A iii -> I iv -> S v -> C _____________________________________________________________________________ objection Enhancement Request Number 184 prindle@voicenet.com Bug in XBDd3 (rdvk# 215) [prindle.xbd-19] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 11147 (delete SIGIO) _____________________________________________________________________________ Page: 335 Line: 11147 Section: Problem: The terminology "asynchronous socket" is undefined. However "Signal-Driven" is defined in context of sockets. Action: Change "an asynchronous socket" to "a socket in signal-driven mode". But see [prindle.xbd-13] - perhaps this mode doesn't really exist, in which case, delete SIGIO entirely. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 185 kettenis@wins.uva.nl Bug in XBDd3 (rdvk# 91) {mk-1} Sat, 29 Apr 2000 19:41:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: use first alternative _____________________________________________________________________________ Page: 336 Line: 11207 Section: signal.h Problem: The description says that: "ucontext_t structure shall be defined through typedef as described in ". The ucontext_t structure described in ucontext.h (page 414) includes a member uc_mcontext with type mcontext_t. But a definition of mcontext_t in signal.h is currently not permitted. Action: Add the line: The mcontext_t type shall be defined through typedef as described in marked with XSI. Or perhaps the inclusion of should be allowed. _____________________________________________________________________________ Editorial Enhancement Request Number 186 donnte@microsoft.com Bug in XBDd3 (rdvk# 187) [DT-XBD-91] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: replace with "Any" _____________________________________________________________________________ Page: 338 Line: 11270 Section: signal Problem: Empty cell in the table is confusing. Action: Add "All others". _____________________________________________________________________________ editorial Enhancement Request Number 187 prindle@voicenet.com Bug in XBDd3 (rdvk# 200) Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 342-343 Line: 11411,11419,11450,11453 Section: [prindle.xbd-4] Problem: posix_spawnattr_getdefault() should be posix_spawnattr_getsigdefault() posix_spawnattr_setdefault() should be posix_spawnattr_setsigdefault() This editorial error was discovered during final pre-publication editing of 1003.1d. Note that the correct name is used throughout .1d, and only appears misspelled this way in the synopsis section and the header section of the example. It is spelled correctly elsewhere. During the merge into Austin D3 the misspelled version seems to have propogated everywhere! This problem also applies to: page 343 line 26782,26784 section posix_spawnattr_destroy() Action: Fix the spelling of these functions everywhere (I've attempted to locate all the occurrences, but Acrobat's find function is not all that reliable). ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 188 drepper@redhat.com Bug in XBDd3 (rdvk# 31) {ud-33} Sat, 15 Apr 2000 01:08:54 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 343 Line: 11440-11441 Section: Problem: For the posix_spawnattr_getschedparam/posix_spawnattr_setschedparam functions one needs the definitions of struct sched_param. But the inclusion of is currently not permitted. Action: Change the paragraph in lines 11440-11441 to: Inclusion of the header may bmake visible symbols defined in the , , and headers. _____________________________________________________________________________ editorial Enhancement Request Number 189 drepper@redhat.com Bug in XBDd3 (rdvk# 30) {ud-30} Sat, 15 Apr 2000 01:08:54 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 343 Line: 11440 Section: Problem: Typo: Inclusion of the header [...] This should be Inclusion of the header [...] Action: Change semaphore.h to spawn.h _____________________________________________________________________________ objection Enhancement Request Number 190 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 54) [tog-c99-xdb 19] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 344 Line: 11464 Section: stdarg.h Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Add the following after line 11464: void va_copy(va_list dest, va_list src); _____________________________________________________________________________ objection Enhancement Request Number 191 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 55) [tog-c99-xdb 20] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 344 Line: 11478 Section: stdarg.h Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Add the following text after line 11478: The va_copy() macro initializes dest as a copy of src, as if the va_start() macro had been applied to dest followed by the same sequence of uses of the va_arg() macro as had previously been used to reach the present state of src. Neither the va_copy() nor va_start() macro shall be invoked to reinitialize dest without an intervening invocation of the va_end() macro for the same dest. _____________________________________________________________________________ objection Enhancement Request Number 192 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 56) [tog-c99-xdb 21] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 344 Line: 11492 Section: stdarg.h Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Change "The va_end( ) macro is used to clean up; it invalidates ap for use (unless va_start( ) is invoked again)." To "The va_end( ) macro is used to clean up; it invalidates ap for use (unless va_start( ) or va_copy() is invoked again). Each invocation of the va_start() and va_copy() macros shall be matched by a corresponding invocation of the va_end() macro in the same function." _____________________________________________________________________________ objection Enhancement Request Number 193 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 57) [tog-c99-xdb 22] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 345 Line: 11529 Section: stdbool.h Problem: Change required for alignment with C99 (ref C99 section 7.16). Action: Add the following header after line 11529: NAME stdbool.h - boolean type and values SYNOPSIS #include DESCRIPTION The functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of symbols in this header. The header shall define the following macros: bool which expands to _Bool. true which expands to the integer constant 1. false which expands to the integer constant 0. __bool_true_false_are_defined which expands to the integer constant 1. A program may undefine and then possibly redefine the macros bool, true and false. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO None. CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 194 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 58) [tog-c99-xdb 23] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 346 Line: 11663 Section: stdint.h Problem: Change required for alignment with C99 (ref C99 section 7.18). Action: Add the following header after line 11663: NAME stdint.h - integer types SYNOPSIS #include DESCRIPTION The functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std. 1003.1-200x, Section 2.2, The Compilation Environment) to enable the visibility of symbols in this header. The header declares sets of integer types having specified widths, and defines corresponding sets of macros. It also defines macros that specify limits of integer types corresponding to types defined in other standard headers. Types are defined in the following categories: integer types having certain exact widths; integer types having at least certain specified widths; fastest integer types having at least certain specified widths; integer types wide enough to hold pointers to objects; integer types having greatest width. (Some of these types may denote the same type.) Corresponding macros specify limits of the declared types and construct suitable constants. For each type described herein that the implementation provides, shall declare that typedef name and define the associated macros. Conversely, for each type described herein that the implementation does not provide, shall not declare that typedef name nor shall it define the associated macros. An implementation shall provide those types described as required, but need not provide any of the others (described as optional). INTEGER TYPES ============= When typedef names differing only in the absence or presence of the initial u are defined, they shall denote corresponding signed and unsigned types as described in ISO/IEC 9899:1999, section 6.2.5; an implementation providing one of these corresponding types shall also provide the other. In the following descriptions, the symbol N represents an unsigned decimal integer with no leading zeros (e.g., 8 or 24, but not 04 or 048). Exact-width integer types ========================= The typedef name intN_t designates a signed integer type with width N, no padding bits, and a twos complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. The typedef name uintN_t designates an unsigned integer type with width N. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits. These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names. Minimum-width integer types =========================== The typedef name int_leastN_t designates a signed integer type with a width of at least N, such that no signed integer type with lesser size has at least the specified width. Thus, int_least32_t denotes a signed integer type with a width of at least 32 bits. The typedef name uint_leastN_t designates an unsigned integer type with a width of at least N, such that no unsigned integer type with lesser size has at least the specified width. Thus, uint_least16_t denotes an unsigned integer type with a width of at least 16 bits. The following types are required: int_least8_t uint_least8_t int_least16_t uint_least16_t int_least32_t uint_least32_t int_least64_t uint_least64_t All other types of this form are optional. Fastest minimum-width integer types =================================== Each of the following types designates an integer type that is usually fastest to operate with among all integer types that have at least the specified width. The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements. The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N. The following types are required: int_fast8_t uint_fast8_t int_fast16_t uint_fast16_t int_fast32_t uint_fast32_t int_fast64_t uint_fast64_t All other types of this form are optional. Integer types capable of holding object pointers ================================================ The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: intptr_t The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: uintptr_t These types are optional. Greatest-width integer types ============================ The following type designates a signed integer type capable of representing any value of any signed integer type: intmax_t The following type designates an unsigned integer type capable of representing any value of any unsigned integer type: uintmax_t These types are required. LIMITS OF SPECIFIED-WIDTH INTEGER TYPES ======================================= The following object-like macros specify the minimum and maximum limits of the types declared in . Each macro name corresponds to a similar type name in section "Integer types". Each instance of any defined macro shall be replaced by a constant expression suitable for use in #if preprocessing directives, and this expression shall have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. Its implementation-dependent value shall be equal to or greater in magnitude (absolute value) than the corresponding value given below, with the same sign, except where stated to be exactly the given value. Limits of exact-width integer types =================================== * minimum values of exact-width signed integer types INTN_MIN exactly -(2**N-1) * maximum values of exact-width signed integer types INTN_MAX exactly 2**N-1 - 1 * maximum values of exact-width unsigned integer types UINTN_MAX exactly 2**N - 1 Limits of minimum-width integer types ===================================== * minimum values of minimum-width signed integer types INT_LEASTN_MIN -(2**N-1 - 1) * maximum values of minimum-width signed integer types INT_LEASTN_MAX 2**N-1 - 1 * maximum values of minimum-width unsigned integer types UINT_LEASTN_MAX 2**N - 1 Limits of fastest minimum-width integer types ============================================= * minimum values of fastest minimum-width signed integer types INT_FASTN_MIN -(2**N-1 - 1) * maximum values of fastest minimum-width signed integer types INT_FASTN_MAX 2**N-1 - 1 * maximum values of fastest minimum-width unsigned integer types UINT_FASTN_MAX 2**N - 1 Limits of integer types capable of holding object pointers ========================================================== * minimum value of pointer-holding signed integer type INTPTR_MIN -(2**15 - 1) * maximum value of pointer-holding signed integer type INTPTR_MAX 2**15 - 1 * maximum value of pointer-holding unsigned integer type UINTPTR_MAX 2**16 - 1 Limits of greatest-width integer types ====================================== * minimum value of greatest-width signed integer type INTMAX_MIN -(2**63 - 1) * maximum value of greatest-width signed integer type INTMAX_MAX 2**63 - 1 * maximum value of greatest-width unsigned integer type UINTMAX_MAX 2**64 - 1 LIMITS OF OTHER INTEGER TYPES ============================= The following object-like macros specify the minimum and maximum limits of integer types corresponding to types defined in other standard headers. Each instance of these macros shall be replaced by a constant expression suitable for use in #if preprocessing directives, and this expression shall have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. Its implementation-dependent value shall be equal to or greater in magnitude (absolute value) than the corresponding value given below, with the same sign. * limits of ptrdiff_t PTRDIFF_MIN -65535 PTRDIFF_MAX +65535 * limits of sig_atomic_t SIG_ATOMIC_MIN see below SIG_ATOMIC_MAX see below * limit of size_t SIZE_MAX 65535 * limits of wchar_t WCHAR_MIN see below WCHAR_MAX see below * limits of wint_t WINT_MIN see below WINT_MAX see below If sig_atomic_t (see ) is defined as a signed integer type, the value of SIG_ATOMIC_MIN shall be no greater than -127 and the value of SIG_ATOMIC_MAX shall be no less than 127; otherwise, sig_atomic_t is defined as an unsigned integer type, and the value of SIG_ATOMIC_MIN shall be 0 and the value of SIG_ATOMIC_MAX shall be no less than 255. If wchar_t (see ) is defined as a signed integer type, the value of WCHAR_MIN shall be no greater than -127 and the value of WCHAR_MAX shall be no less than 127; otherwise, wchar_t is defined as an unsigned integer type, and the value of WCHAR_MIN shall be 0 and the value of WCHAR_MAX shall be no less than 255. If wint_t (see ) is defined as a signed integer type, the value of WINT_MIN shall be no greater than -32767 and the value of WINT_MAX shall be no less than 32767; otherwise, wint_t is defined as an unsigned integer type, and the value of WINT_MIN shall be 0 and the value of WINT_MAX shall be no less than 65535. MACROS FOR INTEGER CONSTANTS ============================ The following function-like macros expand to integer constants suitable for initializing objects that have integer types corresponding to types defined in . Each macro name corresponds to a similar type name in sections "Minimum-width integer types" and "Greatest-width integer types". The argument in any instance of these macros shall be a decimal, octal, or hexadecimal constant with a value that does not exceed the limits for the corresponding type. Macros for minimum-width integer constants ========================================== Each of the following macros expands to an integer constant having the value specified by its argument and a type with at least the specified width. The macro INTN_C(value) shall expand to a signed integer constant with the specified value and type int_leastN_t. The macro UINTN_C(value) shall expand to an unsigned integer constant with the specified value and type uint_leastN_t. For example, if uint_least64_t is a name for the type unsigned long long int, then UINT64_C(0x123) might expand to the integer constant 0x123ULL. Macros for greatest-width integer constants =========================================== The following macro expands to an integer constant having the value specified by its argument and the type intmax_t: INTMAX_C(value) The following macro expands to an integer constant having the value specified by its argument and the type uintmax_t: UINTMAX_C(value) APPLICATION USAGE None. RATIONALE is a subset of more suitable for use in freestanding environments, which might not support the formatted I/O functions. In hosted environments, if the formatted conversion support is not wanted, using this header instead of avoids defining such a large number of macros. FUTURE DIRECTIONS Typedef names beginning with int or uint and ending with _t may be added to the types defined in the header. Macro names beginning with INT or UINT and ending with _MAX, _MIN,or_C may be added to the macros defined in the header. SEE ALSO , , CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ Editorial Enhancement Request Number 195 donnte@microsoft.com Bug in XBDd3 (rdvk# 188) [DT-XBD-92] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: these are limits, in the approved style for limits _____________________________________________________________________________ Page: 347 Line: 11575 Section: stdio Problem: EMB Why are the macro names in the first group wrapped in {}, and those in the second group (which are lexically identical), not? Action: Remove {}. _____________________________________________________________________________ objection Enhancement Request Number 196 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 59) [tog-c99-xdb 24] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 348-349 Line: 11609-111666 Section: stdio.h Problem: Change required for alignment with C99 (ref C99 section 7.19). Action: Change the function prototypes on lines 11609-11666 as shown below: Line 11617: int fgetpos(FILE * restrict, fpos_t * restrict); Line 11618: char *fgets(char * restrict, int, FILE * restrict); Line 11621: FILE *fopen(const char * restrict, const char * restrict); Line 11622: int fprintf(FILE * restrict, const char * restrict, ...); Line 11624: int fputs(const char * restrict, FILE * restrict); Line 11625: size_t fread(void * restrict, size_t, size_t, FILE * restrict); Line 11626: FILE *freopen(const char * restrict, const char * restrict, FILE * restrict); Line 11627: int fscanf(FILE * restrict, const char * restrict, ...); Line 11635: size_t fwrite(const void * restrict, size_t, size_t, FILE * restrict); Line 11644: int printf(const char * retsrict, ...); Line 11653: int scanf(const char * restrict, ...); Line 11654: void setbuf(FILE * restrict, char * restrict); Line 11655: int setvbuf(FILE * restrict, char * restrict, int, size_t); Line 11656: int snprintf(char * restrict, size_t, const char * restrict, ...); Line 11657: int sprintf(char * restrict, const char * restrict, ...); Line 11658: int sscanf(const char * restrict, const char * restrict, int ...); Line 11663: int vfprintf(FILE * restrict, const char * restrict, va_list); Line 11664: int vprintf(const char * restrict, va_list); Line 11665: XSI int vsnprintf(char * restrict, size_t, const char * restrict, va_list; Line 11666: int vsprintf(char * restrict, const char * restrict, va_list); And add the following prototypes: int vfscanf(FILE * restrict, const char * restrict, va_list); int vscanf(const char * restrict, va_list); int vsscanf(const char * restrict, const char * restrict, va_list arg); _____________________________________________________________________________ objection Enhancement Request Number 197 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 60) [tog-c99-xdb 25] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 351 Line: 11736 Section: stdlib.h Problem: Change required for alignment with C99 (ref C99 section 7.20). Action: Add after line 11736: lldiv_t Structure type returned by the lldiv() function. _____________________________________________________________________________ objection Enhancement Request Number 198 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 61) [tog-c99-xdb 26] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 351-352 Line: 11752-11813 Section: stdio.h Problem: Change required for alignment with C99 (ref C99 section 7.20). Action: Change the function prototypes on lines 11752-11813 as shown below: Line 11782: size_t mbstowcs (wchar_t * restrict, const char * restrict, size_t); Line 11783: int mbtowc (wchar_t * restrict, const char * restrict, size_t); Line 11805: double strtod(const char * restrict, char ** restrict); Line 11806: long int strtol(const char * restrict, char ** restrict, int); Line 11807: unsigned long int strtoul(const char * restrict, char ** restrict, int); Line 11812: size_t wcstombs(char * restrict, const wchar_t * restrict, size_t); And add the following prototypes: void _Exit(int); long long int atoll(const char *); long long int llabs(long long int); ldiv_t ldiv(long int, long int); float strtof(const char * restrict, char ** restrict); long double strtold(const char * restrict, char ** restrict); long long int strtoll(const char * restrict, char ** restrict, int); long long int strtoull(const char * restrict, char ** restrict, int); _____________________________________________________________________________ editorial Enhancement Request Number 199 ajosey@opengroup.org Bug in XBDd3 (rdvk# 24) {aj-legacy-1} Mon, 3 Apr 2000 06:47:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 352 Line: 11764 Section: stdlib.h Problem: The ecvt, fcvt, gcvt and mktemp are now LEGACY functions in XSH and need marking appropriately here. Action: Mark Legacy (in parentheses) the ecvt, fcvt, gcvt and mktemp prototypes on this header page. Add a note to the change history: The ecvt, fcvt, gcvt and mktemp functions are marked Legacy. _____________________________________________________________________________ objection Enhancement Request Number 200 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 62) [tog-c99-xdb 27] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 355 Line: 11882-11906 Section: string.h Problem: Change required for alignment with C99 (ref C99 section 7.21). Action: Change the function prototypes on lines 11882-11906 as shown below: Line 11885: void *memcpy(void * restrict, const void * restrict, size_t); Line 11888: char *strcat(char * restrict, const char * restrict); Line 11892: char *strcpy(char * restrict, const char * restrict); Line 11897::char *strncat(char * restrict, const char * restrict, size_t); Line 11899: char *strncpy(char * restrict, const char * restrict, size_t); Line 11904: char *strtok(char * restrict, const char * restrict); Line 11906: size_t strxfrm(char * restrict, const char * restrict, size_t); _____________________________________________________________________________ editorial Enhancement Request Number 201 ajosey@opengroup.org Bug in XBDd3 (rdvk# 25) {aj-legacy-2} Mon, 3 Apr 2000 06:47:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 357 Line: 11946 Section: strings.h Problem: The bcmp, bcopy, bzero, index and rindex functions are now LEGACY functions in XSH and need marking appropriately here. Action: Mark Legacy (in parentheses) the bcmp, bcopy, bzero, index and rindex prototypes on this header page. Add a note to the change history: The bcmp, bcopy, bzero, index and rindex functions are marked Legacy. _____________________________________________________________________________ objection Enhancement Request Number 202 prindle@voicenet.com Bug in XBDd3 (rdvk# 216) [prindle.xbd-20] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A new notation should be introduced for multiple shading options and footnotes used. _____________________________________________________________________________ Page: 365 Line: 12214 Section: Problem: This header contains some symbols used by none of the options named. Need to add the Advisory Information and Typed Memory Objects options to this list. Action: Add bulleted, shaded text "The Advisory Information option". Mark with margin code ADV. Add bulleted, shaded text "The Typed Memory Objects option". Mark with margin code TYM. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 203 prindle@voicenet.com Bug in XBDd3 (rdvk# 203) [prindle.xbd-7] Mon, 01 May 2000 16:26:49 -0400 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As 202 _____________________________________________________________________________ Page: 365 Line: 12234 Section: Problem: These symbols (below) are required to be defined only if ADV is supported AND either of MF|SHM is supported. Action: As in XSH posix_madvise(), somehow indicate here that they are required to be defined only if MF|SHM is also supported. Notationallly, I can't suggest how to do this - probably in the text like posix_madvise(). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 204 drepper@redhat.com Bug in XBDd3 (rdvk# 6) {ud-3} Sat, 25 Mar 2000 23:39:25 GMT _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 374 Line: 12485 Section: Problem: The descriptions states that SHMLBA is a "symbolic constant". My objection is against "constant". Most systems want SHMLBA to be the pagesize of the architecture which even on one architecture might vary. It is especially a problem for libraries covering more than one architecture. In these cases it is a good idea to make SHMLBA a hidden function call returning the page size but then this symbol is not anymore a constant. This is already common practice (on Linux and Solaris, maybe others). Action: Since SHM_RDONLY and SHM_RND really should be constants SHMLBA should be removed from this list and a new paragraph added after line 12486: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Symbolic values: SHMLBA Segment low boundary address multiple ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _____________________________________________________________________________ editorial Enhancement Request Number 205 drepper@redhat.com Bug in XBDd3 (rdvk# 88) {ud-53} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 376 Line: 12546 Section: Problem: The structure sockaddr_storage is described in words instead of using the C syntax. The latter would be more easily readble. Action: Replace the beginning of paragraph in lines 12546 to 12551 with: The sockaddr_storage structure shall contain at least the following members: sa_familty_t ss_family When a sockaddr_storage structure is cast [...] _____________________________________________________________________________ comment Enhancement Request Number 206 drepper@redhat.com Bug in XBDd3 (rdvk# 79) {ud-43} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 381 Line: 12769 Section: Problem: The introduction sentence for the symbolic names of the various bits in a value of type mode_t reads: The following symbolic names for the values of st_mode shall also be defined. This would be OK if there wouldn't be the following reference to these definitions in (line 8723f): The symbolic names for file modes for use as values of mode_t shall be defined as described in . Action: Change the sentence in to: The following symbolic names for the values of type mode_t shall also be defined. This will include the values of st_mode since it has the type mode_t. _____________________________________________________________________________ Objection Enhancement Request Number 207 donnte@microsoft.com Bug in XBDd3 (rdvk# 189) [DT-XBD-93] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: too many applications use these _____________________________________________________________________________ Page: 381 Line: 12771 Section: stat Problem: The masks (as opposed to the macros) are not necessarily all that portable. The macros are. Action: Mark legacy. _____________________________________________________________________________ objection Enhancement Request Number 208 drepper@redhat.com Bug in XBDd3 (rdvk# 10) {ud-4} Sat, 25 Mar 2000 23:48:43 GMT _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 395 Line: 0 Section: Problem: The man page misses references to for the types size_t and ssize_t. Action: Add after line 13186 the paragraph: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ssize_t and size_t types shall be defined as described in . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _____________________________________________________________________________ Objection Enhancement Request Number 209 donnte@microsoft.com Bug in XBDd3 (rdvk# 190) [DT-XBD-94] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 383 Line: 12812 Section: stat Problem: S_ISLNK is no longer just XSI. Action: Remove code, shading. _____________________________________________________________________________ editorial Enhancement Request Number 210 ajosey@opengroup.org Bug in XBDd3 (rdvk# 28) {aj-legacy-5} Mon, 3 Apr 2000 06:47:15 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 390 Line: 13023 Section: sys Problem: The ftime function is now a LEGACY function in XSH and needs marking appropriately here. Action: Mark Legacy (in parentheses) the ftime prototype on this header page. Add a note to the change history: The ftime function is marked Legacy. _____________________________________________________________________________ editorial Enhancement Request Number 211 ajosey@opengroup.org Bug in XBDd3 (rdvk# 27) {aj-legacy-4} Mon, 3 Apr 2000 06:47:15 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 391 Line: 13048 Section: sys Problem: The utimes function is now a LEGACY function in XSH and needs marking appropriately here. Action: Mark Legacy (in parentheses) the utimes prototype on this header page. Add a note to the change history: The utimes function is marked Legacy. _____________________________________________________________________________ comment Enhancement Request Number 212 drepper@redhat.com Bug in XBDd3 (rdvk# 13) {ud-6} Sun, 26 Mar 2000 00:13:05 GMT _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 395 Line: 13192 Section: Problem: The man page does not mentioned at all the limit for the number of scatter/gather elements. This is described in the readv and writev definitions in XSH but should at least be mentioned here as well. Action: Replace paragraph on line 13192 with (please rephrase): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The implementation can put a limit on the number of scatter/gather elements which can be processed in one call. The symbol IOV_MAX defined in should always be used to learn about the limits instead of assuming a fixed value. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _____________________________________________________________________________ comment Enhancement Request Number 213 drepper@redhat.com Bug in XBDd3 (rdvk# 11) {ud-5} Sun, 26 Mar 2000 00:00:46 GMT _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 395 Line: 13194 Section: Problem: Traditionally the headers defines a symbol UIO_MAXIOV. The symbols starting with UIO_ are explicitly reserved for definitions from so this will continue to be used. What is missing is a relation between UIO_MAXIOV and IOV_MAX. I don't think it's worthwhile and watned standardizing UIO_MAXIOV but the rational should include a description. Action: Replace line 13194 with (please reword to correct English, I'm using a markup notation to describe the typeface): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Traditionally, the maximum number of scatter/gather elements the system can process in one call were descibed by the symbolic value UIO_MAXIOV. In this standard this value was replaced by the constant IOV_MAX which can be found in . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _____________________________________________________________________________ Objection Enhancement Request Number 214 donnte@microsoft.com Bug in XBDd3 (rdvk# 191) [DT-XBD-95] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 402 Line: 13410 Section: tar Problem: Symlinks are not just XSI. Action: Delete code, shading. _____________________________________________________________________________ Objection Enhancement Request Number 215 donnte@microsoft.com Bug in XBDd3 (rdvk# 192) [DT-XBD-96] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: [add 13610 - 13615 to XSH p29 and shade as XSI] add these to reserved name table as exact matches. Shade as XSI. Add footnote explaining that though these names are not used, they are reserved for historic purposes. _____________________________________________________________________________ Page: 408 Line: 13609 Section: termios Problem: This is wrong in several ways: 1) it's an attempt at normative text in the Application Usage section. 2) It uses the word "must". 3) It probably steps outside the bounds of reasonable standardization and certainly steps outside of the "POSIX prefix" rule imposed on PASC. Action: There are lots of fixes: decide on what the policy should be and the words will fall out. However, I can't decide the policy. My recommendation... delete the whole thing and forget about it. If implementations extend in this space, they're in violation of the standard (because of the namespace pollution rules) ...tough. _____________________________________________________________________________ objection Enhancement Request Number 216 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 63) [tog-c99-xdb 28] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 410 Line: 13633 Section: tgmath.h Problem: Change required for alignment with C99 (ref C99 section 7.22). Action: Add the following entry after line 13633: NAME tgmath.h - type-generic macros SYNOPSIS #include DESCRIPTION The header shall include the headers and and shall define several type-generic macros. Of the and functions without an f (float)orl(long double) suffix, several have one or more parameters whose corresponding real type is double. For each such function, except modf(), there shall be a corresponding type-generic macro. The parameters whose corresponding real type is double in the function synopsis are generic parameters. Use of the macro invokes a function whose corresponding real type and type domain are determined by the arguments for the generic parameters. Use of the macro invokes a function whose generic parameters have the corresponding real type determined as follows: First, if any argument for generic parameters has type long double, the type determined is long double. Otherwise, if any argument for generic parameters has type double or is of integer type, the type determined is double. Otherwise, the type determined is float. For each unsuffixed function in for which there is a function in with the same name except for a c prefix, the corresponding type-generic macro (for both functions) has the same name as the function in . The corresponding type-generic macro for fabs() and cabs() is fabs(). type-generic function function macro -------------------------------------------- acos cacos acos asin casin asin atan catan atan acosh cacosh acosh asinh casinh asinh atanh catanh atanh cos ccos cos sin csin sin tan ctan tan cosh ccosh cosh sinh csinh sinh tanh ctanh tanh exp cexp exp log clog log pow cpow pow sqrt csqrt sqrt fabs cabs fabs If at least one argument for a generic parameter is complex, then use of the macro invokes a complex function; otherwise, use of the macro invokes a real function. For each unsuffixed function in without a c-prefixed counterpart in , the corresponding type-generic macro has the same name as the function. These type-generic macros are: atan2 cbrt ceil copysign erf erfc exp2 expm1 fdim floor fma fmax fmin fmod frexp hypot ilogb ldexp lgamma llrint llround log10 log1p log2 logb lrint lround nearbyint nextafter nexttoward remainder remquo rint round scalbn scalbln tgamma trunc If all arguments for generic parameters are real, then use of the macro invokes a real function; otherwise, use of the macro results in undefined behavior. For each unsuffixed function in that is not a c-prefixed counterpart to a function in , the corresponding type-generic macro has the same name as the function. These type-generic macros are: carg cimag conj cproj creal Use of the macro with any real or complex argument invokes a complex function. APPLICATION USAGE With the declarations: #include int n; float f; double d; long double ld; float complex fc; double complex dc; long double complex ldc; functions invoked by use of type-generic macros are shown in the following table: macro use invokes ----------------------------------- exp(n) exp(n), the function acosh(f) acoshf(f) sin(d) sin(d), the function atan(ld) atanl(ld) log(fc) clogf(fc) sqrt(dc) csqrt(dc) pow(ldc,f) cpowl(ldc, f) remainder(n,n) remainder(n, n), the function nextafter(d,f) nextafter(d, f), the function nexttoward(f,ld) nexttowardf(f, ld) copysign(n,ld) copysignl(n, ld) ceil(fc) undefined behavior rint(dc) undefined behavior fmax(ldc,ld) undefined behavior carg(n) carg(n), the function cproj(f) cprojf(f) creal(d) creal(d), the function cimag(ld) cimagl(ld) cabs(fc) cabsf(fc) carg(dc) carg(dc), the function cproj(ldc) cprojl(ldc) RATIONALE Type-generic macros allow calling a function whose type is determined by the argument type, as is the case for C operators such as + and *. For example, with a type-generic cos macro, the expression cos((float)x) will have type float. This feature enables writing more portably efficient code and alleviates need for awkward casting and suffixing in the process of porting or adjusting precision. Generic math functions are a widely appreciated feature of Fortran. The only arguments that affect the type resolution are the arguments corresponding to the parameters that have type double in the synopsis. Hence the type of a type-generic call to nexttoward, whose second parameter is long double in the synopsis, is determined solely by the type of the first argument. The term type-generic was chosen over the proposed alternatives of intrinsic and overloading. The term is more specific than intrinsic, which already is widely used with a more general meaning, and reflects a closer match to Fortrans generic functions than to C++ overloading. The macros are placed in their own header in order not to silently break old programs that include , for example with printf("%e", sin(x)). modf(double, double *) is excluded because no way was seen to make it safe without complicating the type resolution. The C Standard differs from an earlier proposal in that the type is determined solely by the argument, and may be narrower than the type for expression evaluation. This change was made because the performance costs for computing functions with narrow arguments to wide range and precision might be too high, even if the implementation efficiently evaluates basic operations to wider format. Also, this differs from earlier proposals in that integer-type arguments are converted to double instead of float. Although converting to float would have been more consistent with the usual arithmetic conversions, converting to double has the advantages of preserving the value more often on many systems, and of being more compatible with C89 where unsuffixed calls to math functions with integer arguments were calls to double functions. Having a g suffix for the generic macros was considered but thought unnecessary. The implementation might, as an extension, endow appropriate ones of the macros that this standard specifies only for real arguments with the ability to invoke the complex functions. The C Standard does not prescribe any particular implementation mechanism for generic macros. It could be implemented simply with built-in macros. The generic macro for sqrt, for example, could be implemented with #undef sqrt #define sqrt(x) _ _BUILTIN_GENERIC_sqrt(x) Generic macros are designed for a useful level of consistency with C++ overloaded math functions. The great majority of existing C programs are expected to be unaffected when is included instead of or . Generic macros are similar to the C89 library masking macros, though the semantic types of return values differ. The ability to overload on integer as well as floating types would have been useful for some functions, for example copysign. Overloading with different numbers of arguments would have allowed reusing names, for example remainder for remquo. However, these facilities would have complicated the specification; and their natural consistent use, such as for a floating abs or a two-argument atan, would have introduced further inconsistencies with C89 for insufficient benefit. The C Standard in no way limits the implementation's options for efficiency, including inlining library functions. FUTURE DIRECTIONS None. SEE ALSO , . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. _____________________________________________________________________________ objection Enhancement Request Number 217 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 64) [tog-c99-xdb 29] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 410 Line: 13655 Section: time.h Problem: Change required for alignment with C99 (ref C99 section 7.23). Action: Change "int tm_sec Seconds [0,61]." To "int tm_sec Seconds [0,60]." [Ed note: Add to CH, The range for seconds is change from 0,61 to 0,60 for alignment with ISO/IEC 9899:1999 C.] _____________________________________________________________________________ editorial Enhancement Request Number 218 drepper@redhat.com Bug in XBDd3 (rdvk# 89) {ud-54} Sun, 30 Apr 2000 03:50:19 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 411 Line: 13702, Section: Problem: Functions introduced for thread-safety are not marked appropriately. Action: Shade lines 13702, 13711, and 13717 and mark them with TSF. _____________________________________________________________________________ objection Enhancement Request Number 219 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 65) [tog-c99-xdb 30] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 411 Line: 13720 Section: time.h Problem: Change required for alignment with C99 (ref C99 section 7.23). Action: Change "size_t strftime(char *, size_t, const char *, const struct tm *);" To "size_t strftime(char * restrict, size_t, const char * restrict, const struct tm * restrict);" _____________________________________________________________________________ editorial Enhancement Request Number 220 kettenis@wins.uva.nl Bug in XBDd3 (rdvk# 231) {mk-2} Sat, 29 Apr 2000 19:46:52 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 414 Line: 13787 Section: ucontext.h Problem: The NAME section has the text "ucontext -- user context". This is inconsistent. Other header file descriptions include the .h suffix in the text in the NAME section.Cha Action: Change the line to: ucontext.h -- user context _____________________________________________________________________________ editorial Enhancement Request Number 221 drepper@redhat.com Bug in XBDd3 (rdvk# 12) {ud-7} Sun, 26 Mar 2000 00:19:58 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 414 Line: 13807 Section: Problem: The prototype for makecontext is wrong. More specific, the type of the second parameter. First, the parenthesis is in the wrong place. Second, the parameter list of the function type should contain void. Action: Replace the prototype inline 13807 with: void makecontext(ucontext_t *, void (*)(void), int, ...); _____________________________________________________________________________ Objection Enhancement Request Number 222 donnte@microsoft.com Bug in XBDd3 (rdvk# 193) [DT-XBD-97] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 416 Line: 13875 Section: unistd Problem: Which "this"? Action: "If this" "If _XOPEN_XCU_VERSION". _____________________________________________________________________________ Comment Enhancement Request Number 223 donnte@microsoft.com Bug in XBDd3 (rdvk# 194) [DT-XBD-98] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Harmonize these values to the year of approval of the spec _____________________________________________________________________________ Page: 417 Line: 13913 Section: unistd Problem: To answer the question: yes. Action: Yes. _____________________________________________________________________________ objection Enhancement Request Number 224 ajosey@opengroup.org Bug in XBDd3 (rdvk# 93) {c99-unistd.h-1} Sun, 30 Apr 2000 09:01:07 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 422 Line: 14138 Section: unistd.h Problem: As part of the introduction of the new c99 utility, we need to mark obsolete (LEGACY) the macros associated with the data models used by c89 , and introduce new macros for the data models used by c99. (see also the changes to create the c99 man page XCUd3 c99-c99-1) Action: Copy lines 14138-14211 inclusive, renaming occurrences of "_CS_XBS5" to "_CS_V6" and "_SC_XBS5" to "_SC_V6" These should have no shading, i.e. become mandatory. Retain existing lines 14138-14211 as XSI, but mark each as LEGACY. Copy lines 14324-14327 , renaming occurrences of _SC_XBS5 to _SC_V6. Retain existing lines 14324-14327 as XSI, but mark each as LEGACY Add to Change History The macros associated with the c89 programming models are marked as LEGACY and new equivalent macros associated with c99 are introduced. _____________________________________________________________________________ comment Enhancement Request Number 225 drepper@redhat.com Bug in XBDd3 (rdvk# 23) {ud-25} Sun, 2 Apr 2000 08:40:07 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 427 Line: 14375 Section: Problem: The introduction of gethostname() from XNS makes another type necessary: socklen_t. But this type is not yet mentioned in the section titled "Type Definitions" or anywhere else on the man page. Action: Add at or after line 14375: The socklen_t type shall be defined as described in . _____________________________________________________________________________ objection Enhancement Request Number 226 drepper@redhat.com Bug in XBDd3 (rdvk# 8) {ud-9} Sun, 26 Mar 2000 00:35:24 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_227 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 428 Line: 14421 Section: Problem: The function getwd is marked in the man page only as XSI which some people might regard as an invitation to use it. But this is one of the worst functions(*) ever invented and should ideally be withdrawn. Second best solution, and this is what I actually propose, is to mark the function as LEGACY. They should be phased out. I would file an appropriate request for the man page of the function but there is none. (*) Why getwd() is bad you ask? It's a gigantic security hole since the caller cannot control length of the buffer the result is written to. getcwd() should be used. Action: Mark getwd() in line 14421 as LEGACY. _____________________________________________________________________________ editorial Enhancement Request Number 227 ajosey@opengroup.org Bug in XBDd3 (rdvk# 26) {aj-legacy-3} Mon, 3 Apr 2000 06:47:15 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 428 Line: 14421 Section: unistd.h Problem: The getwd function is now LEGACY functions in XSH and needs marking appropriately here. Action: Mark Legacy (in parentheses) the getwd prototype on this header page. Add a note to the change history: The getwd function is marked Legacy. _____________________________________________________________________________ Comment Enhancement Request Number 228 donnte@microsoft.com Bug in XBDd3 (rdvk# 195) [DT-XBD-99] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 429 Line: 14468 Section: unistd Problem: Add rat (at beginning of section). Action: Add: "As the standard evolved, certain options became sufficiently standardized that it was concluded that simply requiring one of the option choices was simpler than retaining the option. However, for backwards compatibility, the option flags (with required constant values) are retained." _____________________________________________________________________________ Editorial Enhancement Request Number 229 donnte@microsoft.com Bug in XBDd3 (rdvk# 196) [DT-XBD-100] Mon, 1 May 2000 11:50:28 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Remove "(????)-" _____________________________________________________________________________ Page: 430 Line: 14501 Section: unistd Problem: "????" (appears as text). Action: Correct (to what??). _____________________________________________________________________________ objection Enhancement Request Number 230 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 66) [tog-c99-xdb 31] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 438-439 Line: 14752-14826 Section: wchar.h Problem: Change required for alignment with C99 (ref C99 section 7.24). Action: Change the function prototypes on lines 14752-14826 as shown below: Line 14753: fwprintf(FILE * restrict, const wchar_t * restrict, ...); Line 14754: int fwscanf(FILE * restrict, const wchar_t * restrict, ...); Line 14768: wchar_t *fgetws(wchar_t * restrict, int, FILE * restrict); Line 14770: int fputws(const wchar_t * restrict, FILE * restrict); Line 14775: size_t mbrlen(const char * restrict, size_t, mbstate_t * restrict); Line 14776: size_t mbrtowc(wchar_t * restrict, const char * restrict, size_t, mbstate_t * restrict); Line 14778: size_t mbsrtowcs(wchar_t * restrict, const char ** restrict, size_t, mbstate_t * restrict); Line 14782: int swprintf(wchar_t * restrict, size_t, const wchar_t * restrict, ...); Line 14783: int swscanf(const wchar_t * restrict, const wchar_t * restrict, ...); Line 14787: int vfwprintf(FILE * restrict, const wchar_t * restrict, va_list); Line 14788: int vwprintf(const wchar_t * restrict, va_list); Line 14789: int vswprintf(wchar_t * restrict, size_t, const wchar_t * restrict, va_list); Line 14791: size_t wcrtomb(char * restrict, wchar_t, mbstate_t * restrict); Line 14792: wchar_t *wcscat(wchar_t * restrict, const wchar_t * restrict); Line 14796: wchar_t *wcscpy(wchar_t * restrict, const wchar_t * restrict); Line 14798: size_t wcsftime(wchar_t * restrict, size_t, const wchar_t * restrict, const struct tm * restrict); Line 14801: wchar_t *wcsncat(wchar_t * restrict, const wchar_t * restrict, size_t); Line 14803: wchar_t *wcsncpy(wchar_t * restrict, const wchar_t * restrict, size_t); Line 14806: size_t wcsrtombs(char * restrict, const wchar_t ** restrict, size_t, mbstate_t * restrict); Line 14809: wchar_t *wcsstr(const wchar_t * restrict, const wchar_t * restrict); Line 14810: double wcstod(const wchar_t * restrict, wchar_t ** restrict); Line 14811: wchar_t *wcstok(wchar_t * restrict, const wchar_t * restrict, wchar_t ** restrict); Line 14812: long int wcstol(const wchar_t * restrict, wchar_t ** restrict, int); Line 14813: unsigned long int wcstoul(const wchar_t * restrict, wchar_t ** restrict, int); Line 14816: size_t wcsxfrm(wchar_t * restrict, const wchar_t * restrict, size_t); Line 14822: wchar_t *wmemcpy(wchar_t * restrict, const wchar_t * restrict, size_t); Line 14825: int wprintf(const wchar_t * restrict, ...); Line 14826: int wscanf(const wchar_t * restrict, ...); And add the following prototypes: int vfwscanf(FILE * restrict, const wchar_t * restrict, va_list); int vswscanf(const wchar_t * restrict, const wchar_t * restrict, va_list); int vwscanf(const wchar_t * restrict, va_list); float wcstof(const wchar_t * restrict, wchar_t ** restrict); long long int wcstoll( const wchar_t * restrict, wchar_t ** restrict, int);" long double wcstold(const wchar_t * restrict, wchar_t ** restrict);" unsigned long long int wcstoull( const wchar_t * restrict, wchar_t ** restrict, int);" [Ed note: Add to CH The following changes are made for for alignment with ISO/IEC 9899:1999 C Various function prototypes are now updated to add the restrict keyword. The functions vfwscanf(), vswscanf(), wcstof(), wcstoll(), wcstold() and wcstoull() are added . ] _____________________________________________________________________________ objection Enhancement Request Number 231 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 33) [tog-c99-xbd 1] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 444 Line: 9775 Section: limits.h Problem: Change required for alignment with C99 (ref C99 section 5.2.4.2.1) Action: Add after line 9775: {LLONG_MIN} Minimum value of type long long int Maximum acceptable value: -9223372036854775807 {LLONG_MAX} Maximun value of type long long int Minimum acceptable value: +9223372036854775807 {ULLONG_MAX} Maximum value of type unsigned long long int Minimum acceptable value: 18446744073709551615 [Ed note: Add to CH The constants LLONG_MIN, LLONG_MAX and ULLONG_MAX are added for alignment with ISO/IEC 9899:1999 C] _____________________________________________________________________________ objection Enhancement Request Number 232 ajosey@rdg.opengroup.org Bug in XBDd3 - c99 (rdvk# 67) [tog-c99-xdb 32] Tue, 18 Apr 2000 21:12:55 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 441 Line: 14880 Section: wctype.h Problem: Change required for alignment with C99 (ref C99 section 7.25). Action: Add after line 14880: int iswblank(wint_t); [Ed note: Add to CH The iswblank function is added for alignment with ISO/IEC 9899:1999 C]

P LATIN CAPITAL LETTER P Q LATIN CAPITAL LETTER Q R LATIN CAPITAL LETTER R S LATIN CAPITAL LETTER S T LATIN CAPITAL LETTER T U LATIN CAPITAL LETTER U V LATIN CAPITAL LETTER V W LATIN CAPITAL LETTER W X LATIN CAPITAL LETTER X Y LATIN CAPITAL LETTER Y Z LATIN CAPITAL LETTER Z [ LEFT SQUARE BRACKET \ REVERSE SOLIDUS \ REVERSE SOLIDUS ] RIGHT SQUARE BRACKET ^ CIRCUMFLEX ACCENT ^ CIRCUMFLEX ACCENT _ LOW LINE _ LOW LINE ` GRAVE ACCENT a LATIN SMALL LETTER A b LATIN SMALL LETTER B c LATIN SMALL LETTER C d LATIN SMALL LETTER D e LATIN SMALL LETTER E f LATIN SMALL LETTER F g LATIN SMALL LETTER G h LATIN SMALL LETTER H i LATIN SMALL LETTER I j LATIN SMALL LETTER J k LATIN SMALL LETTER K l LATIN SMALL LETTER L m LATIN SMALL LETTER M n LATIN SMALL LETTER N o LATIN SMALL LETTER O