Document Number: AUSTIN/32 Title: XBD D1 Aardvark Change Request Report Revision Date: 1999-07-22 Source: Andrew Josey, Chair Action: for review 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 OPEN ERN 4 Duplicate of 7 ERN 5 Duplicate of 7 ERN 6 OPEN 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 OPEN 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 OPEN ERN 77 Accept as marked ERN 78 Duplicate of 77 ERN 79 Accept ERN 80 Accept ERN 81 OPEN 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 OPEN 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 OPEN 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 OPEN ERN 131 Accept ERN 132 Accept ERN 133 Accept ERN 134 Accept ERN 135 Accept as marked ERN 136 OPEN 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_____ Accept as marked below_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: OPEN pending 4 _____________________________________________________________________________ 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_____ Accept as marked below_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: OPEN _____________________________________________________________________________ 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_____ OPEN Rationale for rejected or partial changes: OPEN _____________________________________________________________________________ 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. :1 _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: OPEN _____________________________________________________________________________ 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_____ Duplicate_____ Reject_____ OPEN Rationale for rejected or partial changes: OPEN _____________________________________________________________________________ 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) [Copela