Document Number: AUSTIN/49 Title: XBDd3 Aardvark Change Request Report Revision Date: 2000-05-23 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 OPEN 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 OPEN 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____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ 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 _________________________________________

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