Document Number: AUSTIN/32r1 Title: XBD D1 Aardvark Change Request Report Final Revision Date: 1999-10-29 Source: Andrew Josey, Chair Action: for information This report contains the dispositions of the aardvark comments submitted against the XBD Draft 1. Aardvark Summary Table ______________________ ERN 1 Duplicate of 21 ERN 2 Accept ERN 3 Accept ERN 4 Duplicate of 7 ERN 5 Duplicate of 7 ERN 6 Accept as marked ERN 7 Accept ERN 8 Accept ERN 9 Duplicate of 7 ERN 10 Accept ERN 11 Accept ERN 12 Accept ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Accept as marked ERN 17 Accept ERN 18 Accept ERN 19 Accept as marked ERN 20 Reject ERN 21 Accept as marked ERN 22 Accept as marked ERN 23 Duplicate of 22 ERN 24 Accept as marked ERN 25 Accept ERN 26 Accept as marked ERN 27 Reject ERN 28 Accept ERN 29 Accept ERN 30 Accept as marked ERN 31 Accept as marked ERN 32 Reject ERN 33 Accept ERN 34 Accept ERN 35 Accept ERN 36 Reject ERN 37 Reject ERN 38 Accept as marked ERN 39 Duplicate of 40 ERN 40 Accept as marked ERN 41 Reject ERN 42 Duplicate of 16 ERN 43 Duplicate of 16 ERN 44 Accept ERN 45 Duplicate of 16 ERN 46 Accept ERN 47 Accept as marked ERN 48 Accept as marked ERN 49 Reject ERN 50 Accept ERN 51 Duplicate of 49 ERN 52 Accept as marked ERN 53 Accept as marked ERN 54 Accept ERN 55 Accept ERN 56 Accept as marked ERN 57 Accept ERN 58 Accept as marked ERN 59 Reject ERN 60 Accept ERN 61 Accept ERN 62 Accept as marked ERN 63 Accept as marked ERN 64 Accept ERN 65 Duplicate of 67 ERN 66 Accept ERN 67 Accept as marked ERN 68 Duplicate of 46 ERN 69 Accept ERN 70 Accept ERN 71 Accept ERN 72 Accept ERN 73 Accept as marked ERN 74 Accept as marked ERN 75 Accept as marked ERN 76 Accept as marked ERN 77 Accept as marked ERN 78 Duplicate of 77 ERN 79 Accept ERN 80 Accept ERN 81 Accept as marked ERN 82 Accept ERN 83 Accept as marked ERN 84 Reject ERN 85 Accept as marked ERN 86 Accept ERN 87 Accept as marked ERN 88 Accept as marked ERN 89 Accept as marked ERN 90 Accept ERN 91 Accept ERN 92 Accept ERN 93 Duplicate of 94 ERN 94 Reject ERN 95 Accept ERN 96 Accept as marked ERN 97 Reject ERN 98 Accept as marked ERN 99 Accept as marked ERN 100 Accept as marked ERN 101 Accept as marked ERN 102 Reject ERN 103 Reject ERN 104 Reject ERN 105 Accept ERN 106 Accept as marked ERN 107 Accept ERN 108 Accept as marked ERN 109 Accept ERN 110 Accept ERN 111 Accept ERN 112 Accept as marked ERN 113 Accept as marked ERN 114 Accept ERN 115 Duplicate of 114 ERN 116 Accept ERN 117 Accept ERN 118 Accept ERN 119 Accept as marked ERN 120 Accept as marked ERN 121 Accept ERN 122 Accept as marked ERN 123 Accept ERN 124 Accept ERN 125 Accept as marked ERN 126 Accept as marked ERN 127 Accept ERN 128 Accept as marked ERN 129 Accept as marked ERN 130 Accept ERN 131 Accept ERN 132 Accept ERN 133 Accept ERN 134 Accept ERN 135 Accept as marked ERN 136 Accept as marked ERN 137 Accept ERN 138 Accept as marked DETAILED DISPOSITIONS. _____________________________________________________________________________ comment Enhancement Request Number 1 nick@usenix.org Bug in XBD (rdvk# 2) {2} Sat Jun 5, 12:39am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_21_ Reject_____ Rationale for rejected or partial changes: dup of 21 _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: What is XSI? We have introduced the terms XBD, XSH and XCU (and XRAT for that matter), but this document is full of references to "XSI-Conformance" and extensions for XSI, without any explanation. Action: Add an introductory section describing XSI. _____________________________________________________________________________ editorial Enhancement Request Number 2 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 43) [DWC-XBD-1] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: (American vs. English) If this is an IEEE document, it should use American English spelling. If it is a TOG document, it should use British English spelling. (I believe ISO documents could go either way.) Given that this is an Austin Group document, I don't know which spelling should be used. Action: If this is intended to be a document developed in the US, convert "catalogue" (on Pxv, L564) and other British spellings in this document to "catalog" and other American spellings. If this is intended to be a document developed in the UK, convert "standardization" (on Pii between lines 11 and 12) and other American spellings in this document to "standardisation" and other British spellings. (Note that it will be much easier to convert the entire document to American English than to convert it to British English.) _____________________________________________________________________________ editorial Enhancement Request Number 3 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 44) [DWC-XBD-2] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Done by the editors as part of the style cleanup _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: (representation of explicit characters) In draft 1 of this document set, references to explicit characters (such as '\a') and strings (such as "...") in this draft do not use the quotes to delimit them as they appeared in POSIX.1 and POSIX.2. The lack of quotes that explicitly delimit the C language character constants and strings makes it harder for programmers to interpret the standard's requirements. It also makes it harder for non-programmers to parse some statements. (It is sometimes hard to distinguish literal quotes, parentheses, and brackets with grouping quotes, parentheses, and brackets.) In some cases (such as P107, L3399) it creates an ambiguity in the requirements. (The definition here seems to say that an ellipsis is two periods instead of three periods.) Action: Change "\a" on P6, L135 to "'\a'". Change 'The string ...' on P107, L3399 to 'The string "...".'. Globally change other uses of explicit references to characters to enclose them in single quotes. Globally change other uses of explicit references to strings of characters to enclose them in double quotes. _____________________________________________________________________________ comment Enhancement Request Number 4 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 45) [DWC-XBD-3] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_7 Reject_____ Rationale for rejected or partial changes: dup of 7 _____________________________________________________________________________ Page: xv Line: 449-565 Section: Preface Problem: (TOG, IEEE, & ISO) Given that this is a joint development group, we either need to delete the discussion on The Open Group or add discussions on IEEE and ISO/IEC. Action: Either delete Pxiii-xv, L449-565 or add sections describing IEEE and ISO/IEC similar to the way the current contents describe The Open Group. _____________________________________________________________________________ Objection Enhancement Request Number 5 donn@interix.com BUG in XBD (rdvk# 7) [] Fri, 25 Jun 1999 11:26:04 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_7_ Reject_____ Rationale for rejected or partial changes: dup of 7 _____________________________________________________________________________ Page: xii Line: 450 Section: Preface Problem: This will need to be completely rewritten to meet ISO style rules and to acknowledge the Austin group (rather that TOG) participation. Action: Depends on results of negotiations. This should be kept as an unresolved objection for the time being. _____________________________________________________________________________ objection Enhancement Request Number 6 donn@interix.com Bug in XBD (rdvk# 6) [] Tue Jun 15, 10:06am -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The style changes identified at the Montreal meeting are being implemented in this next draft. Layout and other style discussions with IEEE are ongoing and will be closed out before the next draft. The editors have got feedback from IEEE/ISO on the layout. Manual pages have been confirmed as ok. We have made other changes as per the output of the montreal meeting. _____________________________________________________________________________ Page: xiii Line: 450 Section: Preface Problem: This objection really applies across the board to many others, and falls into the "for the record" category, at the moment. I have NOT seen any details of any discussions between the formal standards bodies and the Austin Group, so some of this may have been addressed. However, I cannot emphasize strongly enough that based on past experience, the formal standards buracracy is not to be taken lightly. The original 1003.1 would have looked a great deal different had it not been for the insistence on the application of formal rules and a need for consistency of style with other standards. It took months of negotiation to get line numbers approved by the ITTF, and then one (important) national body voted negative on each and every POSIX ballot because of line numbers (and some other style things), no matter whether they were informed that the issue had been resolved. This negative ballot came not from the technical experts, but from that national body's buracracy. It would be naive to think that the current style has much of a chance of being approved without significant modification, and if the issues have not been resolved, there's little chance that this effort will result in an approved IEEE, National, or International standard. In some sense, this has to be considered the single most important objection: if the document cannot be approved as formal standard, then why bother at all? Please don't get me wrong: In general I find the current document an improvement (particularly in organization, although the author of the present POSIX organization might not agree). Most of the things that are likely to stand in the way of approval are NOT related to that, but at a finer level of detail: 1) Requirements for stilted language, particularly the use of "shall". (This exists for two reasons: the obvious English usage of the imperative form, in the case of shall, but also a number of issues w.r.t. assuring that translations are accurate and unambiguous. I'm not enough of an expert, but can the subtleties of can/may/shall/should be accureately rendered into all of French, Russian and Japanese, the three additional ISO languages besides English?) 2) Requirements of form to match the ISO "house style". The IEEE was gracious enough to yield to most of the requirements of ISO style, while still going to bat for us on a few really important issues such as line numbers. However, my informal impression of the situation up and down the standards buracracy was "here's a bunch of whipper-snappers (again!) who think they know better than we do what makes a good standard". Going through that again would be tedious and probably introduce at least a year delay (as it did last time), so we need to start NOW on working through the style issues, and making the required style corrections in early drafts, so it's right in the later ones. Again, let me empahsize that there are good reasons behind some of the ISO rules (and nonsense behind others). We should be sure that we DO keep the good reasons, and fight only those battles which are truly important, because we'll win only a few, and those few we choose to fight will themselves provide a significant delay in the work, particularly if they are serialized with the technical work. Action: 1) Arrive at an acceptable (to ISO) style for the document IN TIME FOR DRAFT 2. 2) Convert the document to that style. _____________________________________________________________________________ Comment Enhancement Request Number 7 ajosey@opengroup.org Bug in XBD (rdvk# 28) [TOG-XBD-001] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xii Line: 450 Section: Preface Problem: rdvk #7 from donn@interix.com raises an objection to the preface. The reviewers notes state that this is a left over from the Base documents. At the time of production of draft 1 the project had not been approved as an IEEE project. The preface will be replaced with a new preface later in the project (completion due by draft 3) Action: Leave it to the editors to resolve as already noted in the reviewers note _____________________________________________________________________________ Editorial Enhancement Request Number 8 donn@interix.com Bug in XBD (rdvk# 8) [] Mon Jun 28, 9:28am -0600 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 19 Section: 1.2 Problem: We can't be sure how the application will use it, just how it can be used. Action: "it is used" -> "it can be used". _____________________________________________________________________________ editorial Enhancement Request Number 9 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 46) [DWC-XBD-4] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_7 Reject_____ Rationale for rejected or partial changes: dup of 7 _____________________________________________________________________________ Page: xvi Line: 569-571 Section: Preface Problem: (Issue number) This is XBD6, not XBD5. Action: Change "Issue 5" on Pxvi, L569 to "Issue 6". Change "Issue 5" on Pxvi, L570 to "Issue 6". Change "Issue 5" on Pxvi, L571 to "Issue 6". _____________________________________________________________________________ comment Enhancement Request Number 10 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 47) [DWC-XBD-5] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xviii Line: 633 Section: Trademarks Problem: (unused trademarks) I didn't find any uses of "Openview" in this document set, except listing it as a registered trademark. Action: Remove trademarks that are not used in this document set (other than to list them as trademarks) from the Trademarks page. _____________________________________________________________________________ comment Enhancement Request Number 11 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 48) [DWC-XBD-6] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xix Line: 644-647 Section: Acknowledgements Problem: (IEEE acknowledgement) Given that this document is being jointly developed by IEEE, and ISO/IEC, TOG, I don't see why we need to acknowledge IEEE or IEEE CS PASC any more than we need to acknowledge ISO or TOG contributions. Action: Delete Pxix, L644-647. _____________________________________________________________________________ comment Enhancement Request Number 12 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 49) [DWC-XBD-7] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xx Line: 655-657 Section: Referenced Problem: (Referenced Documents) This paragraph needs to be rewritten so it works in IEEE and ISO standards as well as in TOG Technical Standards. Action: Change Pxx, L655-657 to: The following documents are referenced in this document set: _____________________________________________________________________________ comment Enhancement Request Number 13 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 50) [DWC-XBD-8] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xxiii Line: 658-818 Section: Referenced Problem: (Referenced Documents) I haven't verified this, but I can't believe that all of the documents in this section are actually referenced in XBD6, XCU6, or XSH6. Action: Check all of documents listed here and remove entries for each document that is not referenced in XBD6, XCU6, or XSH6. I won't mind if this action is deferred until a decision is made as to whether XNS will be merged into this document set. But, this has to happen before this document set is adopted. _____________________________________________________________________________ objection Enhancement Request Number 14 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 51) [DWC-XBD-9] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xxi Line: 737,738 Section: Referenced Problem: (Issue number) This document is part of Issue 6, not Issue 5. As an Austin Group document (rather than a TOG document), TOG documents shouldn't be segregated from other documents. Action: Delete Pxxi, L736-738 and merge the lists before and after this paragraph into a single sorted list. _____________________________________________________________________________ editorial Enhancement Request Number 15 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 52) [DWC-XBD-10] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: xxii Line: 763-765 Section: Referenced Problem: (Referenced Documents) The entries in the Referenced Documents list should be in alphabetic order. XNS should follow XBD, XCU, and XNFS. Action: Move Pxxii, L763-765 to follow Pxxiii, L798. _____________________________________________________________________________ comment Enhancement Request Number 16 Frank Bug in XBD (rdvk# 106) [prindle.xbd-2] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We need to have consistent names for individual volumes and a consistent way to refer. No specific action required for this one item, but editors agree to take this approach for specifics as they occur. _____________________________________________________________________________ Page: 2 Line: 62 Section: 1.3 Problem: I understand that the "names" of these specifications are really not well defined yet, so this comment is a place-holder. I assume that throughout the document, the terms "the XCU specification", "the XSH specification", "the XBD specification", etc. are used consistently (for now) for self/cross reference among the draft documents. Action: When the ultimate long and short names are decided, replace all occurences of these current spec names with the agreed upon short name. For example, "the XCU specification" on this page might be "POSIX.2". ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 17 Frank Bug in XBD (rdvk# 105) [prindle.xbd-1] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2 Line: 71-73 Section: 1.3 Problem: This text is a bit confusing as it stands. Action: Change "the description is marked." to "the description is marked with the OF code and shading." and join lines 72-73 into the same paragraph after this sentence. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 18 Frank Bug in XBD (rdvk# 108) [prindle.xbd-4] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 74-112 Section: 1.3 Problem: The set of codes documented here differ from the sets of codes documented in the corresponding section of XSH and XCU. I would expect XBD to be the official document defining all codes, with these repeated verbatim in XSH and XCU only for convenience. Action: Include all codes which apply to any of XBD, XSH, or XCU here. Do not include these codes at all in XSH or XCU -or- (for convenience of the reader) include the exact same code descriptions in XSH and XCU, indicating that these are identical to those in XBD and reproduced for convenience; it is permissible in XSH and XCU to omit codes which do not appear in the particular spec, though I suspect this would be more trouble than it is worth (in keeping the docs sync'ed). ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 19 donn@interix.com BUG in XBD. (rdvk# 99) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Create a definition in the definitions chapter for XSI, and add a cross reference to that definition in the codes section. _____________________________________________________________________________ Page: 3 Line: 77 Section: 1.3 Problem: And to respond to Andrew's comments: If a term is used in XBD, it should be defined there. If a term is used in more than one of the other volumes it should be defined in XBD, so there is only one definition. (As we have found from experience, any time there are two of anything normative, one will get out of sync, sooner or later.) This specifically applies to the XSI notation, as well as several of the others (probably all, but???). If the documents are to be read as a single set, then knowing that all definitions are in XBD makes them easier to find. (Or are we going to do a single index spanning all 3 logical and (probably) 5 physical volumes. Or will that be another volume itself?) (No... I wouldn't object to a non-normative short summary of the notations in the other volumes, but keep the official stuff in one place.) Action: The definition of XSI (etc) should be moved here. _____________________________________________________________________________ Objection Enhancement Request Number 20 donn@interix.com Bug in XBD (rdvk# 9) [] Mon Jun 28, 9:28am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: see problem statement in 21 for rationale _____________________________________________________________________________ Page: 3 Line: 77 Section: 1.3 Problem: Similarly to someone else's objection "XSI" is not only undefined, but a strange mnemonic (carrying over from the days of X/Open). Does it even apply any longer, or should all instances of it either be made normal parts of the document or discarded? (There's nothing preventing a profile, such as the SUS, from restoring omitted elements.) Action: Delete the string "XSI" everywhere, and resolve the features to either be in or out of the new standard. (Similarly for all other such notations that represent leftovers from this document being a profile of POSIX.) _____________________________________________________________________________ Objection Enhancement Request Number 21 ajosey@opengroup.org Bug in XBD (rdvk# 29) [TOG-XBD-002] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Place extracts from the problem statement on why XSI is needed into rationale. Don't take the action from here, but implement the action in ERN #19. _____________________________________________________________________________ Page: 3 Line: 77 Section: 1.3 Problem: This is an objection to rdvk #9 from donn@interix.com. The proposed action misunderstands some of the basic principles of the project. A couple of points to note about the XSI notation and organization of the document set. (i) These documents are to be read as a set - they are one logical document , there is one approved PAR. The splitting into the existing physical volumes is a publishing matter (note that the XSH is most likely to be published in a two volume set). The definition of XSI at the moment is described in XSH/XCU in the conformance section. It does seems clear that we need to have some description/cross reference at a minimum in XBD to the conformance sections where this is spelt out. The proposed replacement action below suggests one. (ii)Onto why XSI? For now, It has been assumed that POSIX conformance would not equate to UNIX conformance for these Base volumes. XSI is used to describe the extensions over POSIX for conformance requirements for the Single UNIX Specification. See the diagram in the reviewers note and the conformance section in XSH and XCU for an understanding of XSI. The term XSI has been used for 10 years in connection with the XPG series and the first and second versions of the base volumes of the Single UNIX Specification. XSI, refers to the X/Open System Interface, that is the application programming interface for C and sh programming. (iii) These documents are to act as both an IEEE standard and an Open Group technical standard. There would be one core set of documents - the note in the problem statement suggesting the Single UNIX Spec to split its base documents would be a major divergence from the intended goal of the project. New functionality is being considered for merging into the POSIX base (the initial suggestions have a reviewers note at the top of the man pages in XSH, or are marked MAN on the man page), but until all is merged, we need to retain a marking (or markings) for extensions. (v) The action statement also says "(Similarly for all other such notations that represent leftovers from this document being a profile of POSIX.)" This needs to be specific. Which "other such notations"? The notations UP,OP,PI,UN are already stated in the long scope as being subject to review , with a view to resolving the text so they are not needed. Notations such as SHM are for POSIX options. Without specifics this is impossible to action, even if it were to be agreed. Action: Reject rdvk #9 from donn@interix.com (suggesting removal of all XSI markings) Add text cross referencing the XSH/XCU specifications at the first use of XSI (page 3 line 76) as follows: Change "The functionality described is an XSI extension." to "The functionality described is an XSI extension (see section 2 of XSH, and section 2 of XCU for a description of the X/Open System Interface extension. )." _____________________________________________________________________________ editorial Enhancement Request Number 22 nick@usenix.org Bug in XBD (rdvk# 1) {1} Sat Jun 5, 12:39am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete 82-86, since the POSIX options are now marked as such this statement is no longer true, its a left over from XSH5. _____________________________________________________________________________ Page: 3 Line: 82 Section: 1.3 Problem: "Some optional POSIX System Interfaces behavior is mandated on conforming systems. Such behaviors (for example, those dependent on the availability of mapped files) might not be individually marked as extensions, but the mandatory nature of the feature is marked as an extension where the option is described, typically in the header where the corresponding symbolic constant is defined." This is poor English, and very hard to parse and understand. Further it is not at all obvious when you read this why we have mandatory options! It even uses a new term, not defined earlier "might" ... :-( Action: Replace with: For some POSIX System Interfaces, optional behavior is mandated on conforming systems. However, profiles of this \*(St need not mandate this behavior. Such behavior (for example, behavior dependent on the availability of mapped files) is not individually marked as an extension, but the mandatory nature of the feature is marked as an extension where the option is described, typically in the header where the corresponding symbolic constant is defined. _____________________________________________________________________________ comment Enhancement Request Number 23 evought@qlue.com Bug in XBD (rdvk# 121) {[QCI 1]} Wed, 14 Jul 1999 13:50:07 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_22 Reject_____ Rationale for rejected or partial changes: dup of 22 _____________________________________________________________________________ Page: 3 Line: 82-86 Section: 1.3 Problem: This paragraph is difficult to follow and not well written (even when taking into account action in aardvark #19). This comment is compatible with the action in aardvark #19 and should be used in conjunction with it. I think that this change will make the intent of the paragraph more clear. Action: Change the sentence: Such behavior (for example, behavior dependent on the availability of mapped files) is not individually marked as an extension, but the mandatory nature of the feature is marked as an extension where the option is described, typically in the header where the corresponding symbolic constant is defined. with: Such behavior (for example, behavior dependent on the availability of mapped files) is not individually marked as an extension but the mandatory nature of the underlying feature is indicated by labelling it as an extension where the option is described, typically in the header where the corresponding symbolic constant is defined. _____________________________________________________________________________ objection Enhancement Request Number 24 Frank Bug in XBD (rdvk# 107) [prindle.xbd-3] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The aim is to get rid of OP markings and remove the code once its no longer used. The editors will search for use of OP in all three volumes and once gone remove it. The second part of this action is covered by ERN #18. _____________________________________________________________________________ Page: 3 Line: 99-101 Section: 1.3 Problem: The code OP no longer appears to be used in XSH or XCU, having presumably been replaced by the SPECIFIC option code on which the functionality is dependent. Also, unlike XSH and XCU, there is no reference here to the additional codes for specific options. I think it would be best if one did not have to look in multiple places for codes, but that ALL codes should be introduced here (I have no problem with them being repeated as they are now in section 2.1.6 of XSH and XCU). Also note that some specific option codes are referenced within XBD, and thus rightly belong here. An example is SHM which appears on page 31, line 757. Action: Remove these lines. Instead, list and describe in this section all codes for specific options, thereby creating a master reference for margin codes. ------------------------------------------------------------------------------- _____________________________________________________________________________ editorial Enhancement Request Number 25 Frank Bug in XBD (rdvk# 109) [prindle.xbd-5] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 6 Line: 156-157 Section: 2.12 Problem: When the phrase "the XSH specification" or "the XCU specification" is used elsewhere, the XSH and XCU is not BOLD. Action: Everywhere these phrases are used, make XSH, XCU, XBD bold, consistently. Or, as the seems to add little value and these phrases will eventually be replaced by the agreed-upon short name for the standards, eliminate the bold altogether. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 26 donn@interix.com BUG in XBD (rdvk# 10) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: An action has been assigned to HPA to provide text showing a mapping between the name used in the text and official ISO 10646 names. _____________________________________________________________________________ Page: 7 Line: 171 Section: 2.16 Problem: Are all the character names (this is just the first one I noticed) in complete correspondence with the corresponding ISO standards? If so, say so somewhere. If not, they will need to be before the standard can be approved for ISO. Action: (Presumably someone just knows which is true): fix as noted. _____________________________________________________________________________ Comment Enhancement Request Number 27 ajosey@opengroup.org Bug in XBD (rdvk# 30) [TOG-XBD-003] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: See ERN #26 _____________________________________________________________________________ Page: 7 Line: 171 Section: 2.16 Problem: This is a comment against rdvk #10 from donn@interix.com. The terminology used is consistent with that used in POSIX 1003.2. Action: Suggest no change, unless specific problems can be identified with the terminology used by POSIX 1003.2. _____________________________________________________________________________ editorial Enhancement Request Number 28 Frank Bug in XBD (rdvk# 110) [prindle.xbd-6] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 7 Line: 177 Section: 2.18 Problem: Missing hyphen between signal and safe. Action: Add the hyphen. ------------------------------------------------------------------------------- _____________________________________________________________________________ comment Enhancement Request Number 29 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 53) [DWC-XBD-11] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 11 Line: 247 Section: 2.39 Problem: (need definition for special built-in) This definition of Built-In Utility also defines the term "special built-in". In other places in this draft where a definition defines multiple terms (and the terms are not in alphabetic sequence), there is a separate definition for the other terms that point back to the spot that actually defines the term. In this case, "special built-in" is defined on P11, L247-248 in the definition of "Built-In Utility (or Built-In)", but there is no explicit definition of Special Built-In pointing back to this location. Action: Add the text: 2.xxx Special Built-In See Section 2.39 on page 11. with "xxx" replaced by the appropriate sequence number after P50, L1244. Renumber following definitions. _____________________________________________________________________________ Editorial Enhancement Request Number 30 schweikh@noc.dfn.de BUG in XBD (rdvk# 4) [] Sun Jun 6, 12:25pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change sentence to "An array of elements of type char". _____________________________________________________________________________ Page: 12 Line: 281 Section: 2.44 Problem: There's no such thing as a "array of type char". The C community would say "An array of type char[]". (Or "array of char". The type of an array can never be the element type.) Action: Change char to char[] _____________________________________________________________________________ Objection Enhancement Request Number 31 donn@interix.com BUG in XBD (rdvk# 11) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace l 298 with "A software or hardware object that can be used to measure the apparent or actual passage of time." _____________________________________________________________________________ Page: 12 Line: 298 Section: 2.51 Problem: I'm not sure whether this is a tautology or an overbroad statement. (That is, either it tells me nothing or too much.) (I don't see that it eliminates a mechanical wall clock.) Action: "A software or hardware object usually consisting of one or more integers, that can be used to measure the apparent or actual passage of time." _____________________________________________________________________________ Comment Enhancement Request Number 32 schweikh@noc.dfn.de BUG in XBD (rdvk# 5) [] Sun Jun 6, 12:25pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The current text is inherited from existing POSIX.1 and is a "may be" item. _____________________________________________________________________________ Page: 13 Line: 301 Section: 2.52 Problem: The text says "Clock ticks are one of the units that may be used to express a value found in type clock_t." Action: But then, it may not. So this is as useful as stating that "The type integer may store, among others, the value 42." This sentence should be removed. It is content-free. _____________________________________________________________________________ objection Enhancement Request Number 33 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 54) [DWC-XBD-12] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 14 Line: 357 Section: 2.61 Problem: (Composite Graphic Symbol) We don't have a definition for the term "basic letter", but the use here matches the definition of Base Character in section 2.28. Action: Change "basic letter" on P14, L357 to "base character". _____________________________________________________________________________ Objection Enhancement Request Number 34 donn@interix.com BUG in XBD (rdvk# 12) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editors will choose (whether rat or note) _____________________________________________________________________________ Page: 15 Line: 375 Section: 2.64 Problem: References to entities outside of the formal standards arena (such as the Korn shell) need to be done as notes or rationale, not apparently normative text. Action: Convert to Note or rationale (I don't care which). _____________________________________________________________________________ Comment Enhancement Request Number 35 ajosey@opengroup.org Bug in XBD (rdvk# 31) [TOG-XBD-004] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 16 Line: 390 Section: 2.68 Problem: This is a comment against rdvk #13 from donn@interix.com. I disagree. This use of "may" is consistent. Its optional whether a system generate a core file upon abnormal process termination. Action: Do nothing, leave this line unchanged. _____________________________________________________________________________ Comment Enhancement Request Number 36 donn@interix.com BUG in XBD. (rdvk# 100) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN #35 _____________________________________________________________________________ Page: 16 Line: 390 Section: 2.68 Problem: It is unclear to me what the PURPOSE of that sentence is: if the purpose is to grant permission to the implementation, then it's utterly useless, because it's in a space where permission is already tacitly granted. If the purpose is to notify the user that it could happen, it's not granting permission, and "may" is reserved in this document for that purpose. Define the purpose, and the action is clear. Yes, I'm being pedantic, but we're NOT dealing with issues of "normal English" here: we need to be sure that everything is unambiguous because otherwise we get into interpretation requests. (Speaking of which, interpretations for this document, given the set of participants, are going to be a VERRRY interesting process.) Action: As stated previously. _____________________________________________________________________________ Comment Enhancement Request Number 37 donn@interix.com BUG in XBD (rdvk# 13) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: see ERN #35 _____________________________________________________________________________ Page: 16 Line: 390 Section: 2.68 Problem: I think this use of "may" is not consistent with the definition of "may". Action: Try "might"? There's no need to grant permission to implementations to dump core, as it's already a permissable extension. Certainly it's nothing under the direct control of the user. _____________________________________________________________________________ Comment Enhancement Request Number 38 donn@interix.com BUG in XBD (rdvk# 14) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "that can contain" _____________________________________________________________________________ Page: 16 Line: 396 Section: 2.71 Problem: I think this is granting permission (although that's more than needed) to the user, not the implementation, so it should be "can". Action: may->can. _____________________________________________________________________________ Comment Enhancement Request Number 39 donn@interix.com BUG in XBD. (rdvk# 101) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_40 Reject_____ Rationale for rejected or partial changes: dup of 40 _____________________________________________________________________________ Page: 16 Line: 402 Section: 2.74 Problem: TOG-XBD-005 refers to an entry that I didn't submit, but I believe it was the page/line/section above. In any case, isn't "Change this text to:" obvious? As far as changing the 1996 standard: the whole document is open for discussion, so there's no formal problem with doing so. In this case the definition is wrong, but it will have no effect on conformance of implementations to fix it. (In fact, it may make some implementations conformant, in case they DID implement direct I/O for a reason other than performance!) Action: Change the text to read as suggested previously. _____________________________________________________________________________ Comment Enhancement Request Number 40 donn@interix.com BUG in XBD (rdvk# 15) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The following text will be added in a reviewers note for the next draft. This is a possible replacement defn for the next draft, reviewers should indicate which defn they prefer: "An operation that does I/O in a way that is typically not otherwise supported by the system, or which might circumvent the use of system resources." _____________________________________________________________________________ Page: 16 Line: 402 Section: 2.74 Problem: So, if the purpose direct I/O is not to circumvent a system performance optmization, but for some other purpose, it's not direct I/O? Action: "An operation that does I/O in a way that is typically not otherwise supported by the system, or which might circumvent the use of system resources. Such operations typically trade system performance for individual application performance, predictability, or reliability." _____________________________________________________________________________ Comment Enhancement Request Number 41 ajosey@opengroup.org Bug in XBD (rdvk# 32) [TOG-XBD-005] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN 40 _____________________________________________________________________________ Page: 16 Line: 402 Section: 2.71 Problem: This is a comment against rdvk #15 from donn@interix.com. There is no action specified, just words in quotes. Is this suggested replacement text? Note if so, that this is replacement text for 2.2.2.27 from POSIX.1-1996 Action: Donn needs to clarify what his action is. _____________________________________________________________________________ Objection Enhancement Request Number 42 donn@interix.com BUG in XBD. (rdvk# 102) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____ Rationale for rejected or partial changes: dup of 16 _____________________________________________________________________________ Page: 17 Line: 419 Section: 2.79 Problem: ISO has some EXTREMELY strict rules about how inter-standard and intra-standard references are to be made. Note that POSIX.1 says "this part of ISO/IEC 9945" for almost all self-references. That is the result of a 2 year battle by Hal and Mary-Lynne to try to get something more reasonable past ISO. It didn't happen. POSIX has a set of macros for "this document" and various "that document" references, and my recommendation is that those macros be used (and emit a recognizable sequence) so that when the final form of document references is determined that the macro can be changed. Unless major miracles happen, anything that reads decently will be unacceptable in the long run. Action: Use the macros. _____________________________________________________________________________ Objection Enhancement Request Number 43 donn@interix.com BUG in XBD (rdvk# 16) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____ Rationale for rejected or partial changes: dup of 16 _____________________________________________________________________________ Page: 17 Line: 419 Section: 2.79 Problem: "XCU" needs to be converted to appropriate standardsese. Action: Use the appropriate POSIX "that standard" macro. _____________________________________________________________________________ comment Enhancement Request Number 44 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 55) [DWC-XBD-13] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 17 Line: 420-421 Section: 2.79 Problem: (display) The important point here is that utilities need not use file descriptors and the write() function or printf() function to update the screen. There is no need to talk about UNIX systems here. Action: Change "traditional UNIX system file descriptor" on P17, L420-421 to "traditional file descriptor". _____________________________________________________________________________ Comment Enhancement Request Number 45 ajosey@opengroup.org Bug in XBD (rdvk# 33) [TOG-XBD-006] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____ Rationale for rejected or partial changes: dup of 16 (note line ref should have been 419) _____________________________________________________________________________ Page: 17 Line: 491 Section: 2.79 Problem: This is a comment against rdvk #16 from donn@interix.com. The action is not clear. I'm not sure what the "appropriate"... is. At the moment we refer to each physical book within the document set as XSH, XCU and XBD respectively. Within a document we refer to itself as "this document". We should decide whether we want to continue to refer to the books this way and what handle to use to refer to global requirements. Action: None proposed. However some discussion is needed. _____________________________________________________________________________ Comment Enhancement Request Number 46 donn@interix.com BUG in XBD (rdvk# 17) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (note to editor only on line 436) _____________________________________________________________________________ Page: 18 Line: 436, Section: 2.81, Problem: Dot and dot-dot, as defined here, "dangle" bit as to what they're about. Action: Add "In the context of naming files...". _____________________________________________________________________________ Comment Enhancement Request Number 47 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 42) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace line 444 by: "The conversion of an upper case character that has a single-character lower case representation into this lower case representation." _____________________________________________________________________________ Page: 18 Line: 444 Section: 2.84 Problem: Not all characters have a lower case form. Some characters have several lower case forms, depending on context. (Example: consider Greek Sigma.) For a given character set, the lower case form corresponding to a given upper case character may be locale dependent. [I do not know where `Downshifting' is used in this draft standard, but the area is messy and best avoided if possible.] Action: Replace line 444 by: "The conversion of an upper case character that has a (unique) single-character lower case representation (in the current locale) into this lower case representation." _____________________________________________________________________________ comment Enhancement Request Number 48 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 56) [DWC-XBD-14] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete P18, L445-448 and renumber following definitions. _____________________________________________________________________________ Page: 18 Line: 445-448 Section: 2.85 Problem: ((Clock) Drift Rate) The only reference I have been able to find in this document set (other than the definition itself) to the terms "clock drift rate" and "drift rate" is one use of "clock drift rate" in rationale for clock_getres() in XSH. Action: Delete P18, L445-448 and renumber following definitions. If for some reason you decide that this definition must be kept, change "(Clock) Drift Rate" on P18, L445 to "Clock Drift Rate"; change "positive drift rate" on P18, L447 to "positive clock drift rate"; change "negative drift rate" on P18, L447 to "negative clock drift rate"; move the definition to follow P12, L300 to put it in correct sorted order; and renumber the definitions as needed. _____________________________________________________________________________ Comment Enhancement Request Number 49 donn@interix.com BUG in XBD (rdvk# 18) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See ERN #50. Note that there are no interfaces for an application to install drivers, so a driver is part of the implementation _____________________________________________________________________________ Page: 18 Line: 452 Section: 2.86 Problem: More may/might/can. In this case, it should probably be... Action: "A driver might...". _____________________________________________________________________________ Comment Enhancement Request Number 50 ajosey@opengroup.org Bug in XBD (rdvk# 34) [TOG-XBD-007] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 18 Line: 452 Section: 2.86 Problem: This is a comment against rdvk #18 from donn@interix.com. Again I disagree with this may/might issue. Action: Leave text as is. _____________________________________________________________________________ Comment Enhancement Request Number 51 donn@interix.com BUG in XBD. (rdvk# 103) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_49 Reject_____ Rationale for rejected or partial changes: dup of 49 _____________________________________________________________________________ Page: 18 Line: 452 Section: 2.86 Problem: The same as the last may/can discussion: is this making an observation or granting permission? Again it's useless to grant permission redundantly. Action: Use "might" (or move sentence to rationale, as it's an observation in any case). _____________________________________________________________________________ objection Enhancement Request Number 52 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 57) [DWC-XBD-15] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the last sentence on P19, L456-458 _____________________________________________________________________________ Page: 19 Line: 456-458 Section: 2.87 Problem: (Effective Group ID) If is dangerous to list THE set of functions that can access or change an attribute in an evolving set of specifications. You have to be sure that the definitions are updated when functions are added. This definition says that the only ways to change the effective group ID of a process is through the exec family of functions and the setgid() function. The setregid() function can also be used to change the effective group ID. Action: Either delete the last sentence on P19, L456-458 or change "functions and setgid()" on P19, L457-458 to "functions, setgid(), and setregid()". I prefer the first choice. _____________________________________________________________________________ objection Enhancement Request Number 53 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 58) [DWC-XBD-16] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the last sentence on P19, L461-462 _____________________________________________________________________________ Page: 19 Line: 461-462 Section: 2.88 Problem: (Effective User ID) See also my objection DWC-XBD-15. This definition says that the only way to change the effective user ID of a process is through exec and setuid(). The setreuid() function can also be used to change the effective user ID. Also, the reference to "exec" should be to "the exec family of functions", if you keep this sentence. Action: Either delete the last sentence on P19, L461-462 or change "in exec and setuid()" on P19, L462 to "in the exec family of functions, setreuid(), and setuid()". I prefer the first choice. _____________________________________________________________________________ editorial Enhancement Request Number 54 Frank Bug in XBD (rdvk# 111) [prindle.xbd-7] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 19 Line: 473-475 Section: 2.93 Problem: This section is out of alphabetical order. Action: Reverse this section with 2.94. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 55 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 59) [DWC-XBD-17] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 20 Line: 496 Section: 2.99 Problem: (Execute) The definition of execute provided here only applies to its use in XCU; not in XSH. Action: Change "To perform" on P20, L496 to "In the XCU specification, to perform". _____________________________________________________________________________ objection Enhancement Request Number 56 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 60) [DWC-XBD-18] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: . Delete P22, L533-534. Change "permissions, to be returned by stat() or fstat()" on P22, L539 to "permissions.". Add a period to the end of P22, L541. _____________________________________________________________________________ Page: 22 Line: 533-534,539 Section: 2.109 Problem: (File Access Permissions) See also my objection DWC-XBD-15. File access permissions can be changed by fchmod() as well as by chmod() and they can be read by lstat() as well as by stat() and fstat(). The periods at the end of the first two bullet items on P22 are missing. Action: Perform one of the two following sets of actions: 1. Delete P22, L533-534. Change "permissions, to be returned by stat() or fstat()" on P22, L539 to "permissions.". Add a period to the end of P22, L541. 2. Change "chmod()" on P22, L534 to "chmod() and fchmod()". Change "stat() or fstat()" on P22, L534 to "fstat(), lstat(), or stat()". Change "stat() or fstat()" on P22, L538 to "fstat(), lstat(), or stat().". Add a period to the end of P22, L541. I prefer option 1. _____________________________________________________________________________ objection Enhancement Request Number 57 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 61) [DWC-XBD-19] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept___X_ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 25 Line: 623 Section: 2.123 Problem: (File Times Update) See also my objection DWC-XBD-15. File time stamps need to be updated when lstat() is called as well as when stat() and fstat() are called. Action: Change "stat() or fstat()" on P25, L623 to "fstat(), lstat(), or stat()". _____________________________________________________________________________ Objection Enhancement Request Number 58 donn@interix.com BUG in XBD (rdvk# 19) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace the defn as follows: "The current directory associated with the user database (cxref to user database definition). There is also an associated action on the editors to look at the usage of HOME directory/home directory elsewhere _____________________________________________________________________________ Page: 27 Line: 678 Section: 2.138 Problem: Unless $HOME is set readonly, this is not true. cd (with no argument) and cd ~ normally take the shell to wherever the current value of $HOME is set. Action: "The directory named in $HOME, which is usually set to a default value at login time, equal to the directory that the user starts in after logging in." _____________________________________________________________________________ Comment Enhancement Request Number 59 donn@interix.com BUG in XBD (rdvk# 20) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: There was consensus against making the change. It was felt it added no value over the existing text. _____________________________________________________________________________ Page: 29 Line: 730 Section: 2.152 Problem: Vague in the presence of symbolic links. Action: "A synonym for 'hard link' or 'directory entry'. See...". _____________________________________________________________________________ objection Enhancement Request Number 60 Frank Bug in XBD (rdvk# 119) [prindle.xbd-15] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 30 Line: 748-751 Section: 2.159 Problem: All references to "map" in XSH are with respect to a memory mapped file or shared memory object. There is no useage of the term "map" to associate a physical page to a virtual page, although of course the kernel and MMU are doing this all the time. Nonetheless, there is no OS interface to explicitly set up such a mapping. Once 1003.1j is approved, there will be a way to do this, but it still will be via a memory object (typed memory object), so this definition still need not mention physical memory. Action: Remove the phrases "a range of physical memory or", "physical memory or", and "memory or". ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 61 Frank Bug in XBD (rdvk# 112) [prindle.xbd-8] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 31 Line: 757 Section: 2.161 Problem: You are setting a precedent here, and also with all definitions which contain text marked XSI. If you adhere to this precedent, then any definition text that applies to an optional facility (optional in the POSIX sense, not the UNIX sense) should be similarly marked. Also, note that alternative definitions may apply when two different functionalities are referenced with the same name (e.g. POSIX message queues and XSI message queues); in this case, each definition should be marked with the appropriate code. The action section below lists all definition text that I found that should be marked [see also prindle.xbd-11]. There may be some that I did not find. Action: Shade the following text and mark with the appropriate margin code: page 7 line 166-167 section 2.14 Arm (a timer) mark with TMR page 7 line 173-174 section 2.17 Async-Cancel-Safe Function mark with THR page 7 line 179-182 section 2.19 Asynchronously Generated Signal mark with THR page 8 line 184-186 section 2.20 Asynchronous I/O Operation mark with AIO page 8 line 188-189 section 2.21 Asynchronous I/O Completion mark with AIO page 12 line 298-300 section 2.51 Clock mark with TMR page 14 line 359-361 section 2.62 Condition Variable mark with THR page 30 line 748-751 section 2.159 Map mark with MF|SHM [see also prindle.xbd-15] page 31 line 770-771 section 2.165 Message Queue mark with MSG page 31 line 770-771 section 2.165 Message Queue add new definition for XSI style message queue and mark with XSI page 32 line 783-786 section 2.169 Mutex mark with THR page 40 line 1005-1007 section 2.215 Priority mark with PS|TPS page 41 line 1014-1015 section 2.217 Priority-Based Scheduling mark with PS|TPS page 47 line 1147-1151 section 2.254 Scheduling Contention Scope mark with TPS page 48 line 1186-1187 section 2.259 Semaphore mark with SEM page 48 line 1186-1187 section 2.259 Semaphore add new definition for XSI style semaphore and mark with XSI page 48 line 1189-1191 section 2.260 Semaphore Lock Operation mark with SEM page 48 line 1189-1191 section 2.260 Semaphore Lock Operation add new definition for XSI style semaphore lock operation and mark with XSI page 48 line 1193-1195 section 2.261 Semaphore Unlock Operation mark with SEM page 48 line 1193-1195 section 2.261 Semaphore Unlock Operation add new definition for XSI style semaphore unlock operation and mark with XSI page 49 line 1207-1208 section 2.265 Shared Memory Object mark with SHM|XSI [such objects do not exist outside these options] page 53 line 1307-1308 section 2.293 Synchronized I/O Completion mark with SIO page 53 line 1311-1320 section 2.294 Synchronized I/O Data Integrity Completion mark with SIO page 54 line 1322-1324 section 2.295 Synchronized I/O File Integrity Completion mark with SIO page 54 line 1326-1327 section 2.296 Synchronized I/O Operation mark with SIO page 57 line 1418-1423 section 2.311 Thread mark with THR page 57 line 1425-1426 section 2.312 Thread ID mark with THR page 58 line 1428-1430 section 2.313 Thread List mark with THR [see also prindle.xbd-14] page 58 line 1432-1434 section 2.314 Thread-Safe mark with THR page 58 line 1436-1439 section 2.315 Thread-Specific Data Key mark with THR page 58 line 1443-1444 section 2.317 Timer mark with TMR page 58 line 1446-1447 section 2.318 Timer Overrun mark with TMR ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 62 donn@interix.com BUG in XBD (rdvk# 21) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to l 761 and 770 "In the context of programmatic message passing..." Add to l 764 and 767 "In the context of providing natural language messages to the user..." _____________________________________________________________________________ Page: 31 Line: 761-768 Section: 2.162 Problem: This is an unfortunate ordering of entries, because the two, mostly unrelated, meanings of "message" are physically tangled together. Action: Add "In the context of programmatic message passing..." or "In the context of providing natural language messages to the user..." to the appropriate definitions. _____________________________________________________________________________ objection Enhancement Request Number 63 Frank Bug in XBD (rdvk# 113) [prindle.xbd-9] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The definition of the MAN margin code will be added as a reviewers note to the codes section - note that the MAN margin code is an interim code being used during document and will go away in the final document. _____________________________________________________________________________ Page: 34 Line: 843 Section: 2.184 Problem: This is the first instance of the use of margin code MAN. It appears extensively throughout XSH and XCU as well as XBD. It is not defined in the codes or options sections of any of these documents. Action: Define the meaning of margin code MAN in the codes section of 1.3. ------------------------------------------------------------------------------- _____________________________________________________________________________ Objection Enhancement Request Number 64 donn@interix.com BUG in XBD (rdvk# 22) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 37 Line: 907 Section: 2.199 Problem: "although more than two leading slashes are..." is exactly the sort of situation where "shall" is really needed. In the current text, the more passive "are" seems to be more of an observation than a requirement, but this is clearly a (somewhat counter-intuitive!) requirement. Action: "are" -> "shall be". _____________________________________________________________________________ Comment Enhancement Request Number 65 donn@interix.com BUG in XBD. (rdvk# 104) [] Thu Jul 1, 10:13am -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_67 Reject_____ Rationale for rejected or partial changes: dup of 67 _____________________________________________________________________________ Page: 37 Line: 908 Section: 2.199 Problem: The issue of "//". Action: So moved, but since I probably won't be physically present, I'd presume that the prior text had that effect. If not, what is the mechanism for doing that? _____________________________________________________________________________ Comment Enhancement Request Number 66 ajosey@opengroup.org Bug in XBD (rdvk# 35) [TOG-XBD-008] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept the action (null) _____________________________________________________________________________ Page: 37 Line: 908 Section: 2.199 Problem: This is a comment against rdvk #23 from donn@interix.com. This aardvark does not have an specific action to vote upon? I think Donn should really propose a motion. Action: None. _____________________________________________________________________________ Comment Enhancement Request Number 67 donn@interix.com BUG in XBD (rdvk# 23) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This matter was discussed at length. The consensus of the reviewers was that no change should be made. _____________________________________________________________________________ Page: 37 Line: 908 Section: 2.199 Problem: So the issue is brought up: should the // convetion be retained? Is there any continuing constituency for it? A large fraction of the supposedly portable Gnu software biffs this one, and no-one seems to notice, so there isn't much need for it. Action: Vote, and delete or not. (Probably add rationale if retained.) _____________________________________________________________________________ Editorial Enhancement Request Number 68 donn@interix.com BUG in XBD (rdvk# 24) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_46 Reject_____ Rationale for rejected or partial changes: dup of 46 _____________________________________________________________________________ Page: 38 Line: 2.204 Section: 2.204 Problem: Where does the dot operator in the shell fit into this? Does it belong here, or with "dot", or ??? Action: I can write text given a consensus as to what's wanted. _____________________________________________________________________________ Comment Enhancement Request Number 69 ajosey@opengroup.org Bug in XBD (rdvk# 36) [TOG-XBD-009] Thu Jul 1, 9:38am +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 38 Line: 951 Section: 2.204 Problem: This is a comment against rdvk #24 from donn@interix.com. I do not feel that it belongs here as this defines the term "Period" not dot. Action: Do nothing. _____________________________________________________________________________ objection Enhancement Request Number 70 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 62) [DWC-XBD-20] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 39 Line: 967-975 Section: 2.208 Problem: (Portable Character Set) The way this definition is written along with Section 4.1 (Portable Character Set) makes it look like there are two conflicting definitions for Portable Character Set. After digging through both tables, it looks like the definitions are compatible, but they are still confusing. The reference to Table 4-1 on L974-975 should be a pointer to Section 2.209 (where portable filename character set is defined). Action: Change P39, L967-973 to: conforming systems. See Section 4.1 on page 69. Change "See Table 4-1 on page 69." on P39, L974-975 to "See Section 2.209 on page 39.". _____________________________________________________________________________ objection Enhancement Request Number 71 Frank Bug in XBD (rdvk# 114) [prindle.xbd-10] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 41 Line: 1014-1015 Section: 2.217 Problem: This definition should apply to processes as well as threads, as with Priority on page 40. The problem also applies to: page 47 line 1153-1165 section 2.255 Scheduling Policy. Action: Change "thread[s]" to "process[es] or thread[s]" throughout sections 2.217 and 2.255. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 72 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 63) [DWC-XBD-21] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 42 Line: 1058-1059 Section: 2.226 Problem: (Process List) The term "Process List" is not defined in the definition of Thread List. Also, there is no use of the term "process list" in this document set. Action: Delete P42, L1058-1059 and renumber the following definitions. _____________________________________________________________________________ objection Enhancement Request Number 73 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 64) [DWC-XBD-22] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below___X_ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete the last sentence on P44, L1089-1090 _____________________________________________________________________________ Page: 44 Line: 1089-1090 Section: 2.233 Problem: (Real Group ID) See also my objection DWC-XBD-15. The real group ID can be changed by setregid() as well as by setgid(). Action: Delete the last sentence on P44, L1089-1090 or change "setgid()" on P44, L1090 to "setgid() or setregid()". I prefer the first choice. _____________________________________________________________________________ objection Enhancement Request Number 74 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 65) [DWC-XBD-23] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Delete the last sentence on P44, L1096-1097 _____________________________________________________________________________ Page: 44 Line: 1096-1097 Section: 2.235 Problem: (Real User ID) See also my objection DWC-XBD-15. The real user ID can be changed by setreuid() as well as by setuid(). Action: Delete the last sentence on P44, L1096-1097 or change "setuid()" on P44, L1097 to "setreuid() or setuid()". I prefer the first choice. _____________________________________________________________________________ objection Enhancement Request Number 75 Frank Bug in XBD (rdvk# 115) [prindle.xbd-11] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below___X_ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Use PS | TPS or PS TPS (be consistent with usage elsewhere for logical OR notation on margin markers). _____________________________________________________________________________ Page: 47 Line: 1153-1165 Section: 2.255 Problem: Because there is a default scheduling policy in the absence of PS and TPS options, the section need not be shaded or marked with margin codes. However, the phrase "may modify the priorities" in two places should be marked PS and/or TPS because nice() doesn't use the term priority. Action: Mark the phrase "may modify the priorities" as PS and/or TPS. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 76 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 66) [DWC-XBD-24] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make the proposed change in the action below and add a reviewers note "Please check the calculations here. The last term of the current expression adds in a day for every 4th year starting in 1973. (January 1st of the each year following a leap year starting with the first leap year after 1970.) The first term above subtracts a day every 100 years starting in 2001. The last term above adds a day back in every 400 years starting in 2001." _____________________________________________________________________________ Page: 48 Line: 1183-1184 Section: 2.258 Problem: (Seconds Since the Epoch) The expression given for calculating seconds since the epoch on P48, L1183- 1184 has a couple of problems: 1. It doesn't account for leap seconds. 2. It doesn't account for the fact that the years 2100, 2200, and 2300 (as well as three out of every 4 years that are a multiple of 100 after 2400) are not leap years. I'm happy to ignore the first problem (as long as the definition clearly states that leap seconds are not accounted for), but the other problem needs to be corrected before this revision is approved. When POSIX.1 was approved in 1990, this wasn't a serious problem. Almost all hardware used a signed 32-bit time_t type, and that type of time_t expires well before the year 2100. But, with some of the 64-bit operating systems available today, the values stored in an object of type time_t are more restricted by the fact that asctime() and related functions can't display a date later than December 31, 9999 according to the C Standard than by the limits of a 32-bit time_t. Action: Add the following to the end of the expression on P48, L1183-1184: - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 This definition does not account for leap seconds. Please double check my calculations here. The last term of the current expression adds in a day for every 4th year starting in 1973. (January 1st of the each year following a leap year starting with the first leap year after 1970.) The first term above subtracts a day every 100 years starting in 2001. The last term above adds a day back in every 400 years starting in 2001. _____________________________________________________________________________ comment Enhancement Request Number 77 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 67) [DWC-XBD-25] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note that this reference will be fixed when XNS5v2 is merged. _____________________________________________________________________________ Page: 50 Line: 1233 Section: 2.273 Problem: (Socket) Referencing the Networking Services spec is fine in the Single UNIX Specification. But, since it is not part of this document set, it isn't appropriate here. Action: If sockets are moved into XSH in a later draft, change the reference to "the Networking Services specification" on P50, L1233 to point to the appropriate function in XSH. Otherwise, delete "See the Networking Services specification." from P50, L1233 or delete this entire definition and renumber the following definitions. _____________________________________________________________________________ comment Enhancement Request Number 78 Frank Bug in XBD (rdvk# 116) [prindle.xbd-12] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_77 Reject_____ Rationale for rejected or partial changes: dup of 77 _____________________________________________________________________________ Page: 50 Line: 1233 Section: 2.273 Problem: The notation "the Networking Services specification" will need to be replaced by "the XSH specification" (or it's revised name) in a later draft when XNS and .1g are merged into this draft. Right now, all references to a socket reach a dead end here because "the Networking Services specification" is undefined (unless loosely interpreted as XNS Issue 5). Action: Remember to change this reference once XNS/POSIX.1g are merged into the revision. ------------------------------------------------------------------------------- _____________________________________________________________________________ Editorial Enhancement Request Number 79 donn@interix.com BUG in XBD (rdvk# 25) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 1266 Section: 2.282 Problem: Well... maybe it's editorial. In any case, this is a particularly unfortunate page break, with "stream" on one page and "STREAM" on the next. Action: Add "See also STREAM, 2.283." here, and the converse in 2.283. _____________________________________________________________________________ editorial Enhancement Request Number 80 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 68) [DWC-XBD-26] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 55 Line: 1361 Section: 2.302 Problem: (System Databases) The word "that" is misspelled. Action: Change "tha" on P55, L1361 to "that". _____________________________________________________________________________ comment Enhancement Request Number 81 Frank Bug in XBD (rdvk# 117) [prindle.xbd-13] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See the action item response below (note that some of this below applies to XCU) 9907-06. Frank Prindle to check on use of "System Scheduling Priority" in all volumes to see if the term can be replaced with "Nice Value". (ERN 81) Issue: Replacing all occurences of "system scheduling priority" with "nice value". ******************************************************************************* XSH - No changes required. "nice value" is used consistently throughout ******************************************************************************* XBD - Section 2.305 changes: Note that the original wording said: A nice value of zero specifies the default policy of the system. This is incorrect for two reasons (zero and policy) and should be: The symbol NZERO specifies the default nice value of the system. This change, and changing "system scheduling priority" to "nice value" is reflected below. Note that this will have to be alphabetically re-sorted into 2.* because of its new name. page 56 line 1369-1382 section Definitions: replace subsection with: ------------------------------------------------------------------------------- 2.xxx Nice Value A number used as advise to the system to alter process scheduling priorities. Raising the value should give a process additional preference when scheduling a process to run. Lowering the value should reduce the preference and make a process less likely to run. Typically, a process with higher nice value runs to completion more quickly than an equivalent process with lower nice value. The symbol NZERO specifies the default nice value of the system. This definition is not intended to suggest that all processes in a system have priorities that are comparable. Scheduling policy extensions such as adding realtime priorities make the notion of a single underlying priority for all scheduling policies problematic. Some systems may implement the features related to nice to affect all processes on the system, others to affect just the general time-sharing activities implied by this document set, and others may have no effect at all. Because of the use of ``implementation-dependent'' in nice and renice, a wide range of implementation strategies is possible. ------------------------------------------------------------------------------- ******************************************************************************* XCU - page 592-595 section nice() line 22183: change "system scheduling priority" to "nice value". line 22188: same line 22189: same line 22191: same line 22192: same line 22193: same line 22194: same line 22201: same line 22203: same line 22205: same line 22207: same line 22208: same line 22209: same line 22263: same line 22265: same line 22272: same line 22289: same line 22290: change "priority" to "nice value". line 22306: same line 22307: same (twice on same line) line 22311: same line 22315: change "system scheduling priority" to "nice value". line 22316-22321: leave the words "priorities" and "priority" here alone. In this context, these are the proper words. ------------------------------------------------------------------------------- XCU - page 666-668 section ps() line 25122: change "system scheduling priority" to "nice value". line 25221-25222: Either delete these two lines, or change "system scheduling priority" to "nice value". The latter alternative makes only a tiny bit of sense (i.e. an implementation could say: "-o niceval" I suppose). ------------------------------------------------------------------------------- XCU - page 675 section renice() line 25438: change "system scheduling priorities" to "nice values". line 25443: change "system scheduling priorities" to "nice values", and change "system scheduling priority" to "nice value". line 25448: change "system scheduling priority" to "nice value". line 25449: same line 25453: change "system scheduling priorities" to "nice values". line 25465: change "system scheduling priority" to "nice value". line 25467: same line 25469: same line 25470: same line 25522: same line 25523: change "scheduling priority" to "nice value". line 25525: change "system scheduling priority" to "nice value". line 25526: change "scheduling priority" to "nice value". line 25528: change "system scheduling priority" to "nice value". line 25529: change "scheduling priority" to "nice value". line 25531: change "nice values" to "nice value increments" (this was in error). line 25532: delete "0 (the base scheduling priority)," (wrong and not useful). line 25538-25542: replace with ------------- Originally, this utility was written in the historical manner, using the term ``nice value''. This was always a point of concern with users because it was never intuitively obvious what this meant. With a newer version of renice, which used the term ``system scheduling priority'', it was hoped that novice users could better understand what this utility was meant to do. Also, it would be easier to document what the utility was meant to do. Unfortunately, the addition of the POSIX realtime scheduling capabilities introduced the concepts of process and thread scheduling priorities that were totally unaffected by the nice/renice utilities or the nice()/setpriority() functions. Continuing to use the term ``system scheduling priority'' would have incorrectly suggested that these utilities and functions were indeed affecting these realtime priorities. It was decided to revert to the historical term ``nice value'' to reference this unrelated process attribute. ------------- Also, the paragraph on page 595 line 22315-22321 section nice(), as fixed by changes above, should be replicated here, either immediately before the paragraph at line 25538 (my preference), or immediately after that paragraph. ------------------------------------------------------------------------------- FINALLY: Note that my Acrobat Reader has a bug that keeps it from finding a phrase that spans multiple lines. Though I think I've caught all of these, the editors are strongly urged to do a search of the troff source for "system scheduling priority" (even across lines) after applying the changes (if the group accepts the changes) just to make sure I haven't missed any. Sincerely, Frank Prindle prindle@voicenet.com _____________________________________________________________________________ Page: 56 Line: 1369-1382 Section: 2.305 Problem: This definition seems to relate to "nice value". But it appears to be referenced nowhere, and thus seems superfluous. Perhaps it was meant to set the stage for dealing with the issue of "nice value" vs. "priority" in the strict sense, but this is unclear. This just seems to introduce a meta-priority concept on top of "priority" and "nice value", which should be kept separate and distinct. I am really unclear why this definition exists. Action: Either use this defined term somewhere in XBD or XSH, or delete this definition. ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 82 Frank Bug in XBD (rdvk# 118) [prindle.xbd-14] Wed, 7 Jul 1999 19:26:27 -0500 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 58 Line: 1428-1430 Section: 2.313 Problem: This definition diverges from POSIX (and is also WRONG). It uses "processes" where "threads" was intended. Action: Replace "processes" by "threads" on each of these 3 lines. ------------------------------------------------------------------------------- _____________________________________________________________________________ Comment Enhancement Request Number 83 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 41) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace line 1453 by: "The conversion of a lower case character that has a single-character upper case representation into this upper case representation." _____________________________________________________________________________ Page: 59 Line: 1453 Section: 2.320 Problem: Not all characters have an upper case form. Some characters have several upper case forms, depending on context. Sometimes the upper case representation of a single character consists of two characters. For a given character set, the upper case form corresponding to a given lower case character may be locale dependent. (Examples: consider German sharp s, Spanish ll, Dutch ij. Turkish distinguishes `i' and `dotless i' with capital forms `dotted I' and `I'. That is, in ISO 8859-9 the upper case form of SMALL LETTER i (06/09) is CAPITAL LETTER I WITH DOT ABOVE (13/13) in a Turkish locale, but is CAPITAL LETTER I (04/09) in most other locales.) [I do not know where `Upshifting' is used in this draft standard, but the area is messy and best avoided if possible.] Action: Replace line 1453 by: "The conversion of a lower case character that has a (unique) single-character upper case representation (in the current locale) into this upper case representation." (Or, preferably: delete any mention of `Upshifting' from the entire standard.) _____________________________________________________________________________ Comment Enhancement Request Number 84 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 39) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: See the definition of "executable file", it includes more than just object files. _____________________________________________________________________________ Page: 60 Line: 1478 Section: 2.324 Problem: The definition of utility seems to exclude utilities written in Java or utilities that are perl scripts, etc. Action: Delete in lines 1477-1479 the sentence "This program is ... the shell." _____________________________________________________________________________ Comment Enhancement Request Number 85 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 40) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change "a true" to "an" _____________________________________________________________________________ Page: 60 Line: 1484 Section: 2.324 Problem: The mention of performance characteristics and the word `only' are inappropriate. Action: Replace in lines 1484-1487 the text ", but only ... true executable file." by ". Such a function or built-in utility may differ from other utilities in invocation behaviour: it need not be found using the command search order described in the XCU specification, Section 3.9.2, Command Search and Execution." _____________________________________________________________________________ Objection Enhancement Request Number 86 donn@interix.com BUG in XBD (rdvk# 26) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 1501-1504 -> rationale _____________________________________________________________________________ Page: 60 Line: 1504 Section: 2.326 Problem: As previously objected, Korn shell should be in rationale or a note. Action: Move to rationale or note (I don't care which). _____________________________________________________________________________ objection Enhancement Request Number 87 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 69) [DWC-XBD-27] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "executes wait() or waitpid()" on P62, L1548-1549 to "waits for it to terminate". _____________________________________________________________________________ Page: 62 Line: 1548-1549 Section: 2.337 Problem: (Zombie Process) See also my objection DWC-XBD-15. The waitid() function can also be used to wait for a child to terminate. Action: Choose one of the following: 1. Change "executes wait() or waitpid()" on P62, L1548-1549 to "waits for it to terminate". 2. Change "wait() or" on P62, L1548 to "wait(), waitid(), or". I prefer the first choice. _____________________________________________________________________________ Comment Enhancement Request Number 88 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 38) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: "A process that has terminated and will be deleted when its exit status has been reported to another process waiting for that process to terminate." _____________________________________________________________________________ Page: 62 Line: 1548 Section: 2.337 Problem: The process doing the wait() need not be the zombie's parent. (But it is the process that has the zombie's parent process ID as process ID.) Action: Write: "A process that has terminated and will be deleted when its exit status has been reported to a process executing wait() or waitpid()." _____________________________________________________________________________ Comment Enhancement Request Number 89 Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 37) [] Thu Jul 1, 4:07pm +0200 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: change 1555 to "when the representation allows the sign to be determined." remove lines 1556-1557 _____________________________________________________________________________ Page: 62 Line: 1556 Section: 2.339 Problem: The sentence is logically incorrect: a precision does not have a representation. The sentence is semantically incorrect: integer values do not have distinct representations for +0 and -0 (in two's complement representation). Action: Write something like "If the representation of the value of a variable has separate sign and value parts (as is the case for the common representations of floating point numbers), then the values +0 and -0 can be distinguished. In some circumstances this is significant." The parenthetical part can also be omitted. _____________________________________________________________________________ editorial Enhancement Request Number 90 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 70) [DWC-XBD-28] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 66 Line: 1626 Section: 3 Problem: (File Format Notation) A closing parenthesis in the description of field width has been moved from where it appeared in POSIX.2 to make the parenthetical element contain more text than it contained in POSIX.2. POSIX.2 did it correctly. Action: Change "been given to the field width)." on P66, L1626 to "been given) to the field width.". _____________________________________________________________________________ objection Enhancement Request Number 91 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 71) [DWC-XBD-29] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 67 Line: 1672-1674 Section: 3 Problem: (File Format Notation) The example on P67, L1669-1676 doesn't make sense. In POSIX.2, this example shows that the File Format Notation: "%d\n", could be implemented using a printf() function call: printf("%6d\n", foo); By dropping the "6" from the printf() call, the difference between File Format Notation and printf() format strings is lost. Action: Change '"%d\n"' on P67, L1674 to '"%6d\n"'. _____________________________________________________________________________ objection Enhancement Request Number 92 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 72) [DWC-XBD-30] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 68 Line: 1695 Section: 3 Problem: (File Format Notation) The description of the g and G File Format Notation conversion characters has been changed from the description in POSIX.2. The description in POSIX.2 says that the g and G conversion characters use style f, e, or E and then describes when e is used (meaning that f is used in all other cases). Here, you say that "style g is used only if the exponent" meets certain requirements. This seems to shift the decision on whether to use e, E, or f from the implementation to the application being required to check the value of an entity being printed before using the g and G File Format Notation conversion characters. Action: Change "style g" on P68, L1695 to "style e (or E)". _____________________________________________________________________________ Objection Enhancement Request Number 93 donn@interix.com BUG in XBD (rdvk# 27) [] Tue Jun 29, 5:00pm -0600 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_94 Reject_____ Rationale for rejected or partial changes: dup of 94 _____________________________________________________________________________ Page: 70 Line: 1787 Section: 4.1 Problem: What is the goal of requiring that the characters in the portable character set be positive? This would appear to require that an EBCDIC-based system treat char type as unsigned, regardless of any other justification for treating char type as signed. Action: Justify or remove. _____________________________________________________________________________ Objection Enhancement Request Number 94 Jeffrey bug in XBD (rdvk# 122) [Copeland-xbd-1] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: The review group consensus was that this draws an incorrect conclusion. The text has been here since XPG4 and vendors supporting EBCDIC have not see a problem here. _____________________________________________________________________________ Page: 70 Line: 1788-1789 Section: 4.1 Problem: This phrasing restricts us to character sets which represent the portable characters in 7 bits on machines with signed chars, and thus (for example) prevents EBCDIC from being used as a character set. Action: Remove the sentence "Moveover, if the value is stores in an object of C-language type char, it is guaranteed to be positive..." _____________________________________________________________________________ editorial Enhancement Request Number 95 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 73) [DWC-XBD-31] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 71 Line: 1830 Section: 4.3 Problem: (C Language Wide-Character Codes) The parenthetical element after "wide-character strings (see Section 4.3)" points to itself. It should point to the definition of wide-character strings. Action: Change "(see Section 4.3)" on P71, L1830 to "(see Section 2.231 on page 61)". _____________________________________________________________________________ Comment Enhancement Request Number 96 Jeffrey bug in XBD (rdvk# 123) [Copeland-xbd-2] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "portable set" to "portable character set." _____________________________________________________________________________ Page: 72 Line: 1863 Section: 4.4 Problem: We're talking about converting between subsets of charmaps, and are using the same term used to describe the characters in table 4-1, when what we actually mean is the portable filename character set. (On the other hand, it's possible this paragraph is more tangled than I think, in which case the sentences on line 1860-1865 really need to be re-written to be clear.) Action: Change "portable set" to "portable filename character set." _____________________________________________________________________________ Comment Enhancement Request Number 97 Jeffrey bug in XBD (rdvk# 124) [Copeland-xbd-3] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The consensus of the review group is that applications make use of this feature and we do not want to break them. _____________________________________________________________________________ Page: 72 Line: 1894-1900 Section: 4.4 Problem: Settable escape and comment characters in charmap files, while they represent existing practice, are neither necessary nor desirable for portability or readability. Implementations are made simpler by the removal of this feature. They should be deprecated. Action: Mark these paragraphs as deprecated, to be withdrawn. _____________________________________________________________________________ Comment Enhancement Request Number 98 Jeffrey bug in XBD (rdvk# 125) [Copeland-xbd-4] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "followed by an integer formed by one or more decimal digits." to "followed by an integer formed by one or more decimal digits. Both integers must contain the same number of digits." _____________________________________________________________________________ Page: 73 Line: 1918-1919 Section: 4.4 Problem: It's implied that the number of digits in the pair of symbolic names like " ... " can be different. It is foolishness for them to not be the same, since it can be confusing to both machine and human parsers what the actual sequence of character codes is. Action: Change "followed by an integer formed by one or more decimal digits." to "followed by an integer formed by one or more decimal digits. Both integers must contain the same number of digits." [Alternately, explicitly allow the number of digits to be different, but add a note in the rationale explaining the danger of this course of action.] _____________________________________________________________________________ Comment Enhancement Request Number 99 Jeffrey bug in XBD (rdvk# 126) [Copeland-xbd-5] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the text "big endian" will be removed _____________________________________________________________________________ Page: 73 Line: 1948 Section: 4.4 Problem: The term "big endian" is never defined. Action: Add a definition to chapter 2, like: "Big endian: a numeric representation for numbers of greater than one octet where the octets are presented in decreasing order of significance, that is, the most significant octet is presented first, and the least significant octet is presented last." _____________________________________________________________________________ Editorial Enhancement Request Number 100 Jeffrey bug in XBD (rdvk# 127) [Copeland-xbd-6] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: delete the words "by the application" _____________________________________________________________________________ Page: 75 Line: 1981 Section: 5.1 Problem: What "application" are we talking about? Action: Change "the application" to "by the local system administrator or other authorized user". _____________________________________________________________________________ Comment Enhancement Request Number 101 Jeffrey bug in XBD (rdvk# 128) [Copeland-xbd-7] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change line 1984 "even if the ability to create locales, all implementation ...." , also unshade as this is a POSIX requirement _____________________________________________________________________________ Page: 75 Line: 1982 Section: 5.1 Problem: This is at variance with the description of localedef in XCU. This phrasing suggests that support of localedef is optional; XCU now requires it on page 489, line 18155. Which is the intended requirement? Action: Either change "see the XCU specification" to "it is required by the XCU specification." Or remove the corresponding XSI-extension sentence in XCU. _____________________________________________________________________________ Comment Enhancement Request Number 102 Jeffrey bug in XBD (rdvk# 129) [Copeland-xbd-8] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_ Rationale for rejected or partial changes: The environment variable is not the operand described on the localedef manual page. _____________________________________________________________________________ Page: 75 Line: 1990 Section: 5.1 Problem: The description "environment variable begins with a slash" is at variance with the description in the XCU description of the localedef utility, which says (page 490, line 18196) "contains one or more slash characters". Which is it, begins or contains? The less restrictive version is better, since it allows something like LANG=foo/ rather than LANG="$(pwd)/foo/" Action: Change the words "begins with a slash" to "contains one or more slash characters" in XBD. _____________________________________________________________________________ Comment Enhancement Request Number 103 Jeffrey bug in XBD (rdvk# 130) [Copeland-xbd-9] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Reject for the same reason as ERN 97 _____________________________________________________________________________ Page: 77 Line: 2050-2059 Section: 5.3 Problem: Settable escape and comment characters in localedef files, while they represent existing practice, are neither necessary nor desirable for portability or readability. Implementations are made simpler by the removal of this feature. They should be deprecated. Action: Mark these paragraphs as deprecated, to be withdrawn. _____________________________________________________________________________ Comment Enhancement Request Number 104 Jeffrey bug in XBD (rdvk# 131) [Copeland-xbd-10] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The consensus of the review group is that the text is this way intentionally, and that it should be left. _____________________________________________________________________________ Page: 78 Line: 2085-2092 Section: 5.3 Problem: This paragraph is a portability minefield. By using characters outside the portable character set in localedef files, they are no longer portable. Action: Change the opening sentences of the paragraph to "A character can be represented by the character itself, if the character is from the portable character set. Using other characters as themselves is deprecated." Also, remove the eszet from the example on line 2092. _____________________________________________________________________________ Editorial Enhancement Request Number 105 Jeffrey bug in XBD (rdvk# 132) [Copeland-xbd-11] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 80 Line: 2175-2176 Section: 5.3.1 Problem: Surely we mean want to use the portable names for the character, "" instead of "space". Action: Change "space, form-feed, newline, ..." to ", , , ..." Also at page 80 line 2178 section 5.3.1 Editorial page 80 line 2190 section 5.3.1 Editorial page 80 line 2198 section 5.3.1 Editorial page 81 line 2203 section 5.3.1 Editorial page 81 line 2219 section 5.3.1 Editorial page 83 line 2286 section 5.3.1 Editorial _____________________________________________________________________________ Editorial Enhancement Request Number 106 Jeffrey bug in XBD (rdvk# 133) [Copeland-xbd-12] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "the limit {COLL_WEIGHTS_MAX}" to "the limit {COLL_WEIGHTS_MAX} as specified in as defined in ." (where is the appropriate reference). _____________________________________________________________________________ Page: 87 Line: 2497 Section: 5.3.2 Problem: No reference for {COLL_WEIGHTS_MAX}. Action: Change "the limit {COLL_WEIGHTS_MAX}" to "the limit {COLL_WEIGHTS_MAX} as specified in ." _____________________________________________________________________________ Editorial Enhancement Request Number 107 Jeffrey bug in XBD (rdvk# 134) [Copeland-xbd-13] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 89 Line: 2589 Section: 5.3.2 Problem: Missing close angle bracket Action: Change ", ..." _____________________________________________________________________________ Comment Enhancement Request Number 108 Jeffrey bug in XBD (rdvk# 135) [Copeland-xbd-14] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note that we expect the following sentence to change when .2b is merged . _____________________________________________________________________________ Page: 89 Line: 2594 Section: 5.3.2 Problem: Incomplete explanation. Action: After "The NUL character compares lower than any other character." add "even if NUL is explicitly defined elsewhere in the collating order." _____________________________________________________________________________ editorial Enhancement Request Number 109 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 74) [DWC-XBD-32] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 89 Line: 2598 Section: 5.3.2 Problem: (LC_COLLATE--Collation Order) There is an extraneous space. Action: Change "< collating-symbol>" on P89, L2598 to "". _____________________________________________________________________________ Editorial Enhancement Request Number 110 Jeffrey bug in XBD (rdvk# 136) [Copeland-xbd-15] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 91 Line: 2663 Section: 5.3.2 Problem: tabs don't line up Action: Add some extra space before ";" to make the columns line up _____________________________________________________________________________ editorial Enhancement Request Number 111 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 75) [DWC-XBD-33] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 97 Line: 2985 Section: 5.3.4 Problem: (LC_NUMERIC) The text "the strings only can contain integers" is awkward English. Action: Change "only can" on P97, L2985 to "can only". _____________________________________________________________________________ comment Enhancement Request Number 112 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 76) [DWC-XBD-34] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note in the text that: XBD, D1 , ERN 112 raised the following question: (replicate problem/action statement) Reviewers are asked to state their opinion. _____________________________________________________________________________ Page: 98 Line: 3027 Section: 5.3.4 Problem: (LC_NUMERIC) I don't understand why P98, L3019 says that grouping in the POSIX locale is "-1", but the grouping line in the POSIX Locale Value column of the table on P98, L3023-3027 contains "N/A". Action: Change "N/A" on P98, L3027 to "-1". _____________________________________________________________________________ Editorial Enhancement Request Number 113 Jeffrey bug in XBD (rdvk# 137) [Copeland-xbd-16] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept that these should be MAN shading for page 102 line 3164 section 5.3.5 page 102 line 3169-3173 section 5.3.5 _____________________________________________________________________________ Page: 100 Line: 3116-3118 Section: 5.3.5 Problem: Missing shading on part of an extension. Action: Add shading to these lines. Also at page 102 line 3164 section 5.3.5 page 102 line 3169-3173 section 5.3.5 _____________________________________________________________________________ comment Enhancement Request Number 114 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 77) [DWC-XBD-35] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 105 Line: 3337 Section: 5.3.6 Problem: (LC_MESSAGES) The note saying that yesstr and nostr values have changed from the values they had in XBD3 is not appropriate in this Austin-Group document in normative text. Action: Move P105, L3337 to follow P106, L3365. _____________________________________________________________________________ Comment Enhancement Request Number 115 Jeffrey bug in XBD (rdvk# 138) [Copeland-xbd-17] Wed, 14 Jul 1999 13:54:58 -0600 (MDT) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_114 Reject_____ Rationale for rejected or partial changes: dup of 114 _____________________________________________________________________________ Page: 105 Line: 3337 Section: 5.3.6 Problem: We use the legacy "yesstr" and "nostr" in the examples and the table on the following page, but don't specify the operands here. Action: Add the operands back into this description. In XBD5, the phrasing was: yesstr (LEGACY) The operand consists of a fixed string (not a regular expression) that can be used by an application for composition of a message that lists and acceptable affirmative reponse, such as in a prompt. nostr (LEGACY) The operand consists of a fixed string that can be used by an application for composition of a message that lists an acceptable negative response. _____________________________________________________________________________ objection Enhancement Request Number 116 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 78) [DWC-XBD-36] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 106 Line: 3364 Section: 5.3.6 Problem: (LC_MESSAGES--LC_MESSAGES Application Usage) See also my comment DWC-XBD-8. I didn't find a reference to the Internationalization Guide in the referenced documents list. There is an Internationalisation Guide that was part of XPG2, but it doesn't seem reasonable to be referencing that from XBD6. Action: Delete "(see the Internationalization Guide) " from P106, L3364. _____________________________________________________________________________ objection Enhancement Request Number 117 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 79) [DWC-XBD-37] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 108-114 Line: 3427-3640 Section: 5.4.2 Problem: (Locale Grammar) There are lots of extraneous spaces in the grammar presented on pages 108-114. While some of these are strictly editorial and won't make any difference in the meaning of the grammar, others have spaces in quotes that completely change the meaning of the grammar being described. Action: Change "lc_ctype | lc_collate" on P108, L3427 to "lc_ctype | lc_collate". Change "CHAR | CHARSYMBOL" on P108, L3434 to "CHAR | CHARSYMBOL". Change "'upper' | 'lower'" on P109, L3466 to "'upper' | 'lower'". Change "' ;'" on P109, L3471 to "';'". Change "' ;'" on P109, L3472 to "';'". Change "' ;'" on P109, L3478 to "';'". If at all possible, force P110, L3501-3502 to fit on a single line. If that isn't possible, at least force the "'from' on P110, L3502 to be indented more than it currently is. Change "' ;'" on P110, L3509 to "';'". Change "' ;'" on P111, L3529 to "';'". Change "' ;'" on P111, L3530 to "';'". Change "'int_curr_symbol' | 'currency_symbol'" on P112, L3575 to "'int_curr_symbol' | 'currency_symbol'". Change "'int_frac_digits' | 'frac_digits'" on P112, L3582 to "'int_frac_digits' | 'frac_digits'". Change "mon_keyword_grouping :" on P112, L3587 to "mon_keyword_grouping :". Change "' ;'" on P112, L3590 to "';'". Change "' ;'" on P113, L3615 to "';'". Change "' ;'" on P114, L3640 to "';'". _____________________________________________________________________________ objection Enhancement Request Number 118 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 80) [DWC-XBD-38] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 115 Line: 3673 Section: 5.5 Problem: (Locale Definition Example) See also my objection DWC-XBD-36. I didn't find a reference to the Internationalization Guide in the referenced documents list. There is an Internationalisation Guide that was part of XPG2, but it doesn't seem reasonable to be referencing that from XBD6. Action: Delete P115, L3673. _____________________________________________________________________________ editorial Enhancement Request Number 119 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 81) [DWC-XBD-39] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: A reviewers note will be added to ask the question in the next draft _____________________________________________________________________________ Page: 115 Line: 3685 Section: 5.5 Problem: (Locale Definition Example) Most proposed standards that I've seen don't include a date of adoption designator. Is Canadian standard Z243.4.1-1990 a "proposed" standard, or is (or was) it an "approved" standard? Action: If Z243.4.1 is (or was) an approved standard, delete " proposed" from P115, L3685. If the standard has been revised, consider updating this text to refer to the revision. _____________________________________________________________________________ comment Enhancement Request Number 120 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 82) [DWC-XBD-40] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a reviewers note in the text that: XBD, D1 , ERN 120 raised the following problem statement: {replicate problem/proposed action} Reviewers are asked to state their preference. _____________________________________________________________________________ Page: 117 Line: 3765-3772 Section: 5.5 Problem: (Locale Definition Example) I know this text comes directly from POSIX.2 rationale, but this example inside the example is not clear. The "", "", and "" used in this example are not defined in the preceding text. There is no indication of how this encoding would be done or why "" is included at the end of either encoding. Action: Replace P117, L3765-3772 with the following text: # As an example, the strings "Bach" and "bach" would be compared as follows: # In the first pass, both strings would be evaluated as . # In the second pass, both strings would be evaluated as # . # In the third pass, "Bach" would sort after "bach" because "Bach" would # be evaluated as while "bach" would # be evaluated as (and # comes before in the set of collating symbols defined above). _____________________________________________________________________________ comment Enhancement Request Number 121 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 83) [DWC-XBD-41] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 122 Line: 3959 Section: 6.2 Problem: (Internationalization Variables) The environment variables LANG and NLS_PATH do not start with "LC_". Adding "LC_*" in parentheses in this list makes it confusing. Action: Change "The environment variables (LC_*), LANG, LC_ALL" on P122, L3959 to "The environment variables LANG, LC_ALL". _____________________________________________________________________________ editorial Enhancement Request Number 122 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 84) [DWC-XBD-42] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editor will fix the layout appropriately _____________________________________________________________________________ Page: 131 Line: 4266,4267,4271 Section: 7.3.3 Problem: (BRE Special Characters) There are some missing periods at the ends of sentences here. Action: Add a period to the end of P131, L4266. Add a period to the end of P131, L4267. Add a period to the end of P131, L4271. _____________________________________________________________________________ objection Enhancement Request Number 123 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 85) [DWC-XBD-43] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 132 Line: 4318 Section: 7.3.5 Problem: (RE Bracket Expression) The discussion on collating symbols in RE bracket expressions says to see the symbol in an example in Collation Order on page 89, but is not defined on that page or in that section. Action: Change "Collation Order on page 89" on P132, L4318 to "The collating-symbol Keyword on page 88". _____________________________________________________________________________ comment Enhancement Request Number 124 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 86) [DWC-XBD-44] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 133 Line: 4359 Section: 7.3.5 Problem: (RE Bracket Expression) One-to-many mappings are discussed in section 5.3.2 on page 87. LC_COLLATE is mentioned in the introduction to locales in section 5.1 on page 75, but there is no mention of one-to-many mappings until 12 pages later. Action: Change "(see the description of LC_COLLATE in Chapter 5 on page 75)" on P133, L4358-4359 to "(see the description of LC_COLLATE in Section 5.3.2 on page 87)". _____________________________________________________________________________ objection Enhancement Request Number 125 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 87) [DWC-XBD-45] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This will be fixed to fit all on a single line _____________________________________________________________________________ Page: 134 Line: 4395-4396 Section: 7.3.6 Problem: (BREs Matching Multiple Characters) The example showing a valid BRE with ten subexpressions in this draft on P134, L4395-4396 fit on a single (although long) line on POSIX.2, volume 2, P802, L2094 and fit on a single line in XBD5 on P107. When the line was split in this draft a " \c" was added to show that the RE was continued on the next line. But, "\c" in a BRE yields undefined results. (See P131, L4254-4257.) This is an example of a BRE, not an example of a command language that recognizes "\c" as a continuation sequence. If for some reason this BRE can't be presented on a single line in this document, shorten the BRE until it fits. Action: Drop " \c " from P134, L4395-4396. If the resulting string won't fit on a single line, make changes as follows until it does fit on a single line: 1. Drop the point size of the text, 2. change one or more of the subexpressions that contain two letters to only contain a single letter (e.g. change "ab" to "a"), 3. drop the interval expression, and/or 4. drop one or more of the asterisks. I greatly prefer the first option in the list and I prefer the second option over the last two options. _____________________________________________________________________________ comment Enhancement Request Number 126 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 88) [DWC-XBD-46] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editor will fix the layout appropriately _____________________________________________________________________________ Page: 136 Line: 4471,4472,4478 Section: 7.4.3 Problem: (ERE Special Characters) Three sentences in bullet lists in this section are missing terminating periods. The reference to "interval expression" on P136, L4472 should give a pointer to where the term is defined. Action: Add a period to the end of P136, L4471. Add " (see Section 7.5.6 on page 137)." to the end of P136, L4472. Add a period to the end of P136, L4478. _____________________________________________________________________________ editorial Enhancement Request Number 127 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 89) [DWC-XBD-47] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 141 Line: 4664 Section: 7.5.2 Problem: (RE and Bracket Expression Grammar) There are some extra spaces in this grammar. Although this is strictly editorial and won't make any difference in the meaning of the grammar, the extra spaces are distracting. Action: Change "matching_list ']'" on P141, L4664 to "matching_list ']'". _____________________________________________________________________________ editorial Enhancement Request Number 128 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 90) [DWC-XBD-48] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editor will fix the layout appropriately _____________________________________________________________________________ Page: 143 Line: 4743,4744,4745,4747 Section: 7.5.3 Problem: (ERE Grammar) See also my editorial comment DWC-XBD-2. There are several sentences in this section missing terminating periods. Action: Add a period to the end of P143, L4743. Add a period to the end of P143, L4744. Add a period to the end of P143, L4745. Add a period to the end of P143, L4747. _____________________________________________________________________________ objection Enhancement Request Number 129 nick@usenix.org Bug in XBD (rdvk# 3) {3} Sat Jun 5, 12:39am +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to the end of line 4753 - "unless otherwise specified below". _____________________________________________________________________________ Page: 145 Line: 4753 Section: 8.1 Problem: The requirement on line 4753 conflicts with line 4758. Action: Add to the end of line 4743 - "unless otherwise specified below". _____________________________________________________________________________ objection Enhancement Request Number 130 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 91) [DWC-XBD-49] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 146 Line: 4790 Section: 8.2 Problem: (Output Devices and Terminal Types) None of the control characters shown in Table 8-1 are listed in Section 4.1; most are listed in section 5.3.1. Even there, however, , , , , , , and are not listed. You need to add an additional column to Table 8-1 with the heading "Symbolic Name" as listed below to show the correspondence between control character names in this table and symbolic names in the cntrl keyword of LC_CTYPE on page 83. Action: Change "Section 4.1 on page 69" on P146, L4790" to "Section 5.3.1 on page 83". Add an additional column to Table 8-1 with the heading "Symbolic Name" duplicating the corresponding entries except for the differences below: Value Symbolic Name ========== ==================== All others Same in both columns to indicate the relationships between control character values and control character symbolic names. _____________________________________________________________________________ objection Enhancement Request Number 131 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 92) [DWC-XBD-50] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 147 Line: 4840 Section: 9.1.2 Problem: (General Terminal Interface: Process Groups) The meaning of this sentence has been completely reversed. In POSIX.1-1996, P183, L30-32, the corresponding sentence is: When there is no longer any process whose process ID or process group ID matches the process group ID of the foreground process group, the terminal shall have no foreground process group. In XBD5, P119, the corresponding sentence is: When there is no longer any process whose process ID or process group ID matches the process group ID of the foreground process group, the terminal will have no foreground process group. In this draft, the "shall have no" and "will have no" has been changed to "has". The current sentence in this draft is not even correct English. The missing "no" is extremely important here. Action: Change "the terminal has foreground" on P147, L4840 to "the terminal will have no foreground" or to "the terminal shall have no foreground". _____________________________________________________________________________ editorial Enhancement Request Number 132 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 93) [DWC-XBD-51] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4905 Section: 9.1.5 Problem: (General Terminal Interface: Input Processing and Reading Data) There is no fcntrl() function in this document set. Action: Change "fcntrl()" on P149, L4905 to "fcntl()". _____________________________________________________________________________ editorial Enhancement Request Number 133 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 94) [DWC-XBD-52] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 149 Line: 4939 Section: 9.1.7 Problem: (General Terminal Interface: Non-Canonical Mode Input Processing) ISO POSIX-1 refers to the 1996 version of the standard. This should be talking about the revision we're creating. Action: Change "The ISO POSIX-1 standard" on P149, L4939 to "This document set". _____________________________________________________________________________ editorial Enhancement Request Number 134 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 95) [DWC-XBD-53] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 151 Line: 5028-5029 Section: 9.1.9 Problem: (General Terminal Interface: Special Characters) I thought all of the FIPS mandated features in POSIX.1-1996 were supposed to be mandated without markings in this revision. Action: Drop the FIPS marking and the shading on P151, L5028-5029. _____________________________________________________________________________ editorial Enhancement Request Number 135 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 96) [DWC-XBD-54] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "-f" with "f" in bold font on P161, L5348 to put "f" in courier font. Change all occurrences of "-a", "-b", and "-c" with "a", "b", and "c" in bold font on P162, L5361-5364 to put "a", "b", and "c" in courier font. Change "-C, -l, and -1" with "C", "l", and "1" in bold font on P163, L5422 to put "C", "l", and "1" in courier font. _____________________________________________________________________________ Page: 161-163 Line: 5331,5337,5346,5348,5361-5364,5422 Section: 10.1 Problem: (Utility Argument Syntax) There are several font problems with option letters in this section. They frequently appear in italic or bold font when they should appear in a courier font. Action: Change "[-d|-e] [-f" with "d|", "e", and "f" in italic font on P161, L5331 to put "d", "e", and "f" in courier font and put "|" in a non-italic font. Change "-c" with "c" in bold font on P161, L5337 to put "c" in courier font. Change "-c" with "c" in bold font on P161, L5346 to put "c" in courier font. Change "-f" with "f" in bold font on P161, L5348 to put "f" in courier font. Change all occurrences of "-a", "-b", and "-c" with "a", "b", and "c" in bold font on P162, L5361-5364 to put "a", "b", and "c" in courier font. Change "-C, -l, and -1" with "C", "l", and "1" in bold font on P163, L5422 to put "C", "l", and "1" in courier font. _____________________________________________________________________________ objection Enhancement Request Number 136 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 98) [DWC-XBD-56] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editors will do their best, due to timescales this may be deferred to a later draft, if so we'll retain this item as ongoing. We probably need someone to identify all terms to be indexed and markup a draft. _____________________________________________________________________________ Page: 167-171 Line: 0 Section: Index Problem: (Index) There are several problems in the index: 1. There is an inconsistent use of fonts on the page numbers. (Ideally, the place where a term is defined should be in bold font, and the rest should be in Roman font.) 2. All uses of defined terms must be indexed. (This is crucial when trying to find all places where a term is used while trying to implement a conforming system.) 3. The index shouldn't be creating classifications of terms that are not defined in the normative text. (For example, none of the codes defined on page 3 are split into classifications where they are defined, but some are split into the classifications "extension" [see P168, L84-86] and "warning" [see P171, L225-229] in the index.) 4. Some defined terms do not appear in the index at all. (For example, +/-0 is defined in section 2.339. But, it does not appear in the index at all.) Action: Fix the index to address the problems noted above. _____________________________________________________________________________ editorial Enhancement Request Number 137 Don.Cragun@eng.sun.com Bug in XBD (rdvk# 97) [DWC-XBD-55] Thu, 1 Jul 1999 07:38:22 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 163 Line: 5417 Section: 10.1 Problem: (Utility Argument Syntax) There is an extraneous space. Action: Change "SYNOPSIS ." on P163, L5417 to "SYNOPSIS.". _____________________________________________________________________________ Objection Enhancement Request Number 138 donn@interix.com BUG in XBD (rdvk# 120) [] Tue, 13 Jul 1999 13:59:42 -0600 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The review group agrees with the sentiment however notes that the action is not specific. The review group notes that this is being done and would ask all reviewers to highlight any missing rationale in the next draft. _____________________________________________________________________________ Page: 185 Line: 5531 Section: 10.2 Problem: The rationale for this whole section (possibly this whole document, I haven't checked) was not brought forward from the corresponding .2 text. Since this particular piece of rationale contains a particularly important statement, that of forever reserving -W to implementors, I find this a particularly serious omission. Action: Bring forward to this document all the original .1 and .2 rationale that has been deleted (with the appropriate application of editorial license for formatting and dealing with resolved issues.) (See P809 line 2384 of the current .2.)