Document Number: AUSTIN/37 Title: XBD D2 Aardvark Change Request Report Final Revision Date: 1999-12-20 Source: Andrew Josey, Chair Action: for information This report contains the dispositions of the aardvark comments submitted against the XBD Draft 2. This document should be read in conjunction with Austin/36. _____________________________________________________________________________ Objection Enhancement Request Number 1 donnte@microsoft.com BUG in XBD (rdvk# 1) [DT-XBD-1] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 1 Line: 34 Section: 1.2 Problem: The problem is difficult to explain here but easily explained in a later objection. See line 5418. Action: Add to definition of "must": In a situation where the implementor provides a value or behavior that is also (potentially) provided by the user, uses of the word "must" are to be interpreted as if "shall" had been used. _____________________________________________________________________________ Comment Enhancement Request Number 2 donnte@microsoft.com BUG in XBD (rdvk# 2) [DT-XBD-2] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 Need to rework the wording. The intent is as follows: If "|" is not present, it means that for the shaded text to be required that all the options are required to be supported by the implementation. If the "|" is present, then for the shaded text to be required either option is required to be supported by the implementation. _____________________________________________________________________________ Page: 3 Line: 76 Section: 1.3.1 Problem: I may be being dense, but I'm not sure what this paragraph is trying to say. I'm quite sure it's clear if you already know what it means, but since (a) I don't, and (b) I'm making a point of reading the document as if I didn't already know what it was intended to mean, it leaves me lost. If "|" is NOT given, does it mean that for the shaded text to be required that ALL the options are required, or that ANY of the options are required (and conversely if the "|" is omitted). Does "all of the options shall apply" mean that the feature is required only if the implementation provides all of the features coded, or if any of the features are coded? (It isn't clear unless you already know what it means!) In the latter case, how is this different from the "|" case. What can an application count on? (I'd actually be surprised to find very many, if any, situations where only when all of several featues are enabled is something required; I'd normally expect it only when any of them are enabled. It may simplify things to simply eliminiate the "|" option and have the "any" situation be the only choice. If there's an exception to that, include it as explicit normative text at that point.) Action: Say what you mean unambiguously. Since I don't know, I can't say it for you. _____________________________________________________________________________ Editorial Enhancement Request Number 3 donnte@microsoft.com BUG in XBD (rdvk# 3) [DT-XBD-3] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agreed these symbols should no longer be under the text at 306 which makes them appear to be optional. Insert before 303 a new bullet The following symbolic constants shall be defined with a value other than -1. Then move lines 394-395, 398-399, 400-402 to under that item. Delete lines 403-404 _____________________________________________________________________________ Page: 11 Line: 403 Section: 2.1.3.1 Problem: >From line 403, am I to conclude that _POSIX_VDISABLE (et al.) are are always required to be defined? If so then what's the purpose of the text at 396 that appears to allow them to be undefined? I'm guessing that the intent is that the paragraph at 403 should either have XSI shading, or is an editorial artifact of an attempt to make these three options into "former options". Action: 1) Split this bullet item (at line 382) into two items, one with the three named on line 403, the other with the two remaining ones, and make sure the text says what it means without having to introduce an exception. 2) Reread the result for clarity, so that there's no question that it does what was intended. My guess as to the intent (and I *think* it says this, but it's not quite crisp enough): all systems must have the feature, but it's allowable for some sub-part of it to not have it, except that vdisable, saved ids, and job control are not permitted to have a sub-part where it doesn't work. (And if it does say what the last sentence says, my point is made :-) ). _____________________________________________________________________________ Comment Enhancement Request Number 4 donnte@microsoft.com BUG in XBD (rdvk# 4) [DT-XBD-4] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ACCEPT (btw the intent of this text is to make it clear that the IEEE 1003.1-200x system may support the XSI extensions) _____________________________________________________________________________ Page: 12 Line: 433 Section: 2.1.3.1 Problem: I think 433-439 should be shaded, or I don't get what the options coding model is. (See my comment for line 76 above.) Action: Shade or move. _____________________________________________________________________________ Editorial Enhancement Request Number 5 donnte@microsoft.com BUG in XBD (rdvk# 35) [DT-XBD-5] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept this -i.e. to XSI shade section 2.1.4, initially i had hoped to avoid use of the shading in the conformance clause but accept its needed. _____________________________________________________________________________ Page: 13 Line: 460 Section: 2.1.4 Problem: Shouldn't this whole section be shaded (as part of the XSI extension to the base standard). Maybe the text at 433-439 should be moved here? Action: Shade, move text. (If the text at 433 exists to assure implementors that they are permitted to implement the XSI stuff when not claiming XSI, that should be done as a note, rather than normative text.) _____________________________________________________________________________ Editorial Enhancement Request Number 6 donnte@microsoft.com BUG in XBD (rdvk# 5) [DT-XBD-6] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept, XSI shade section 2.1.5.2 _____________________________________________________________________________ Page: 16 Line: 575 Section: 2.1.5.2 Problem: Shade (see comment about line 460 above). Action: Shade. _____________________________________________________________________________ Editorial Enhancement Request Number 7 donnte@microsoft.com BUG in XBD (rdvk# 8) [DT-XBD-9] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 44 Line: 1353 Section: 3.102 Problem: In the general theme of "useful to dictionary editors", this isn't. Action: Recast as a real defintion that is generally useful; the reference to 8.4 is perfectly reasonable as ADDITIONAL information, but it's not a definition as it stands. Also: look for other "defintions" that are simply references to other locations in the document, and replace with a useful definition. _____________________________________________________________________________ Comment Enhancement Request Number 8 donnte@microsoft.com BUG in XBD (rdvk# 6) [DT-XBD-7] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 44 Line: 1360 Section: 3.104 Problem: I believe I understand the intent of the new sentence ("These..."): to be sure that POSIX semantics are preserved properly. However it may be that this sentence has the effect of disallowing all security extenstions. As an example, consider the case where the security system is allowed to deny the existence of a file (an example explicitly noted elsewhere). If a cp command is given to copy TO such a file, it should fail (rather than destroying the file, unless other permissions permit). However, if I take this sentence literally, having the system refuse the copy (EEXIST, probably) would change the semantics of the cp command. (I'm sure that better examples exist, but this makes the point well enough.) Action: Remove, or recast so that the intent is met without breaking the security extensions. (Or... and quite acceptable to me, give up on the security stuff; however, I don't think that others will be happy with that alternative.) _____________________________________________________________________________ Objection Enhancement Request Number 9 donnte@microsoft.com BUG in XBD (rdvk# 7) [DT-XBD-8] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We agree, and will create a General Concepts section in XBD and move "File Access Permissions" into it. Similarly 3.125 File Times Update will go into the new section _____________________________________________________________________________ Page: 45 Line: 1385 Section: 3.110 Problem: This is an "editorial objection", in that the problem is editorial, but it invalidates the standard. If I remember correctly, the definitions section of a standard is prohibited from making normative requirements, for two reasons: 1) that it's not where you'd normally look for normative requirements, and 2) it makes the job of the IEEE dictionary writers (or other dictionary writers) very much harder. (I believe this is an IEEE prohibition, but it may also be reflected in ANSI (and other national body) and ISO rules.) The reason for the existence of the general concepts section in the earlier versions of the the standard was to move the bulk of what appears here out of the definitions section and into a place where normative text was permitted. Action: Move the non-definitional component of this "definition" someplace else (recreate General Concepts). Also: Make sure that other instances of normative text that have crept into the definitions section are removed. _____________________________________________________________________________ Editorial Enhancement Request Number 10 donnte@microsoft.com BUG in XBD (rdvk# 9) [DT-XBD-10] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 47 Line: 1438 Section: 3.117 Problem: This may be another "editorial objection". Assume that the document is to be translated to a language other than English; does the page number 61 work after translation (or would it end up being 59 or 63)? Until recently, it was impractical to have page number reference that work for translations, but with the advent of computer typesetting it may be OK. Action: Get IEEE and ISO permission to include page numbers (if not already obtained, but I don't remember hearing about it). If it can't be obtained, remove them. (All of them.) Note: I'd much prefer that the be retained, so try real hard to convince the editors that it's OK. _____________________________________________________________________________ Objection Enhancement Request Number 11 donnte@microsoft.com BUG in XBD (rdvk# 10) [DT-XBD-11] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate__X__ Reject_____ Rationale for rejected or partial changes: Duplicate of ERN 9 _____________________________________________________________________________ Page: 48 Line: 1470 Section: 3.125 Problem: More normative text in defintions. Action: Move. _____________________________________________________________________________ Editorial Enhancement Request Number 12 donnte@microsoft.com BUG in XBD (rdvk# 11) [DT-XBD-12] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 48 Line: 1476 Section: 3.125 Problem: This is in the -1990 standard, but it is also a "shall" issue that was apparently missed at that time: "are to be" is another form of "shall be". Action: are to be -> shall be. It would be worthwhile to look for other instances of this. _____________________________________________________________________________ Objection Enhancement Request Number 13 donnte@microsoft.com BUG in XBD (rdvk# 12) [DT-XBD-13] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 51 Line: 1553 Section: 3.145 Problem: "Network transparency..." is not properly part of a definition; I suspect this was cut from someplace else and needs to be returned there. (No "function" in the sense of the standard is being described here.) Action: Delete, return as needed. _____________________________________________________________________________ Comment Enhancement Request Number 14 donnte@microsoft.com BUG in XBD (rdvk# 13) [DT-XBD-14] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agreed, these should not be in the definitions section, but will be relocated to a "related standards" section, or removed altogether since they are in the referenced documents section at present. _____________________________________________________________________________ Page: 52 Line: 1563,1567 Section: 3.148 Problem: These are citations, not definitions. I belive they belong in the "related standards" secttion of the citations. Action: Check with IEEE/ISO. _____________________________________________________________________________ Objection Enhancement Request Number 15 donnte@microsoft.com BUG in XBD (rdvk# 14) [DT-XBD-15] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: see Austin/36 _____________________________________________________________________________ Page: 57 Line: 1701 Section: 3.182 Problem: Historically, the nice command has used "backwards" priorities (smaller values run faster). The words "raising" and "lowering" are used in such a way that reading this without prior knowledge of the intent will cause it to be read as "numerically increasing" (resp. "decreasing") the value. Action: A pot shot at a rephrase. Since we're talking about NICE values, not priorities in general, I think this is OK. A number used as advice to the system to alter process scheduing. Numerically smaller values give a process additional preference when scheduling a process to run. Numerically larger values reduce the preference and make a process less likely to run. Typically, a process with a smaller nice value runs to completion more quickly than an equivalent process with a higher nice value. The symbol NZERO specifies the default nice value of the system. _____________________________________________________________________________ Objection Enhancement Request Number 16 donnte@microsoft.com BUG in XBD (rdvk# 15) [DT-XBD-16] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept as per ERN 9, add to General concepts section _____________________________________________________________________________ Page: 61 Line: 1807 Section: 3.208 Problem: Not a definition. See above. Action: As above. _____________________________________________________________________________ Editorial Enhancement Request Number 17 donnte@microsoft.com BUG in XBD (rdvk# 16) [DT-XBD-17] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 62 Line: 1847 Section: 3.210 Problem: Clarity (we're talking about types of patterns, not a specific pattern). Action: "the two patterns" -> "the two types of patterns". _____________________________________________________________________________ Objection Enhancement Request Number 18 donnte@microsoft.com BUG in XBD (rdvk# 17) [DT-XBD-18] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 63 Line: 1871 Section: 3.216 Problem: Not a definition. Action: Fix as above. _____________________________________________________________________________ Editorial Enhancement Request Number 19 donnte@microsoft.com BUG in XBD (rdvk# 18) [DT-XBD-19] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 65 Line: 1920 Section: 3.228 Problem: I'm not sure whether the information in the additional 2 paragraphs (the first is fine) is acceptable as a definition. Action: Ask IEEE/ISO editors. _____________________________________________________________________________ Objection Enhancement Request Number 20 donnte@microsoft.com BUG in XBD (rdvk# 19) [DT-XBD-20] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 66 Line: 1934 Section: 3.230 Problem: "shall" in definitions. Action: Remove (move requirement elsewhere; an *observation* that the standard requires non-reuse is OK, but not the requirement.) Also occurs in other places in this (e.g. 1944). Editor, please search and destroy. _____________________________________________________________________________ Editorial Enhancement Request Number 21 donnte@microsoft.com BUG in XBD (rdvk# 20) [DT-XBD-21] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 73 Line: 2103 Section: 3.271 Problem: In the context of a definition, it's unclear whether the expression is expressed in C or Fortran (or...), and the types of tm_sec (etc.) are not specified; thus the expresion could be done in either fixed or floating point arithmetic. Clearly, fixed point C is intended. Action: Change "according to the expression" to "according to the C-language expression, where tm_sec, tm_hour, tm_yday and tm_year are all integral types". _____________________________________________________________________________ Editorial Enhancement Request Number 22 donnte@microsoft.com BUG in XBD (rdvk# 21) [DT-XBD-22] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 74 Line: 2124 Section: 3.275 Problem: 1) Should be Semaphore (singular), per IEEE definition rules. 2) Grammar error. 3) Is the definition even useful? Action: Should read "A minimal synchronization primitive". However, look in standard dictionaries for a better defintion than this handwave. Make singular. _____________________________________________________________________________ Editorial Enhancement Request Number 23 donnte@microsoft.com BUG in XBD (rdvk# 22) [DT-XBD-23] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept (editorial) _____________________________________________________________________________ Page: 78 Line: 2220 Section: 3.301 Problem: A revision bar of "/" (slash)? Action: Fix. _____________________________________________________________________________ Editorial Enhancement Request Number 24 donnte@microsoft.com BUG in XBD (rdvk# 23) [DT-XBD-24] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: XSI shade the wording _____________________________________________________________________________ Page: 81 Line: 2308 Section: 3.319 Problem: Is the "Conformance Statement Questionnnaire" strictly an Open Group thing, or has that been brought into POSIX? If so, I don't remember seeing it as something to ballot upon. (A normative requirement to something that is not itself part of an approved standard is just not acceptable.) Action: Either shade the CSQ stuff, or bring it into POSIX as normative text. (In many ways, I like the latter alternative, but I don't know whether it will fly thru the standards process, except possibly as an informative addendum.) _____________________________________________________________________________ Editorial Enhancement Request Number 25 donnte@microsoft.com BUG in XBD (rdvk# 24) [DT-XBD-25] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 85 Line: 2416 Section: 3.340 Problem: "Shall" in definition. Action: Remove (no normative text in definitions). _____________________________________________________________________________ Objection Enhancement Request Number 26 donnte@microsoft.com BUG in XBD (rdvk# 25) [DT-XBD-26] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 88 Line: 2445 Section: 3.342 Problem: Reference to Korn shell. I'm not sure what the rules about notes are. Clearly, in the rationale it would be OK to reference the Korn shell, but in a note (which is properly part of the standard, albeit not normative) it may not be acceptable. (There are issues of implied endorsement that may be triggered.) Action: Check with the IEEE editors; if it's OK with them then there's no problem (but do let us know explicitly). If it's not OK with them, then change to "some shell implementations...". _____________________________________________________________________________ Objection Enhancement Request Number 27 donnte@microsoft.com BUG in XBD (rdvk# 26) [DT-XBD-27] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept that this should not have a section number. It will be marked with informative change bars and is part of rationale. We may well remove much of this later. _____________________________________________________________________________ Page: 90 Line: 2533 Section: 3.362 Problem: This certainly isn't a definition, so the section number is wrong. (I think there's a requirement here, but IEEE editors can tell you for sure.) In addition, I'm not sure that Change History is acceptable in ISO/IEEE documents (that's supposed to be reflected in the document's various versions). I don't have a problem with it as long as the ISO and IEEE editors are OK with it, and as long as it reflects the change history of POSIX, not just TOG documents. (TOG change history should be shaded.) Again, either remove or get a ruling. Action: 1) Get official ISO (not just IEEE) ruling on whether it's permissable. 2) If permissable, either put in the POSIX change history information in each such section, and shade the TOG stuff, or delete the section. Also, if you're going to do change history, do it for the normative sections in XBD such as Utility Syntax Guidelines; there are a lot of changes from base POSIX (I haven't even begun to compare for such changes yet, and found a number accidentally). _____________________________________________________________________________ Comment Enhancement Request Number 28 donnte@microsoft.com BUG in XBD (rdvk# 27) [DT-XBD-28] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 92 Line: 2576 Section: 4 Problem: "None" could be interpreted (using a classical terminal model) as "nothing sent over the wire", when the intent clearly is that "\" is printed. Action: Change to: "print the character \". ... or change the column title to "special terminal action" or something similar. _____________________________________________________________________________ Editorial Enhancement Request Number 29 donnte@microsoft.com BUG in XBD (rdvk# 28) [DT-XBD-29] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 92 Line: 2602 Section: 4 Problem: This one needs to be run past the editors as well, but it's a bit odd in that it's what is in the 1992 standard, but I think it's actually editorially wrong. The "shall" on this line is NOT a requirement on either the implementation or the application, but rather on the standard itself, and I don't believe that shall applies in that case. I believe a normal declarative sentence is exactly what's needed. (Mentally substitute "the implementation shall" and "the application must" (etc.) for each shall/must/may/can and see if the sentence makes sense. In this case "the implementation shall" doesn't make any sense.) (This is just a single example of this use of "shall" in this section; fix everywhere.) Action: Run this by the IEEE/ISO editors and do what they say. _____________________________________________________________________________ Editorial Enhancement Request Number 30 donnte@microsoft.com BUG in XBD (rdvk# 29) [DT-XBD-30] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 92 Line: 2602 Section: 4 Problem: In this same text, there's a shall vs. must problem: for STDOUT and STDERR, the "implementation shall" format things as described. However, for STDIN, the "application (or user) must" format things in a way that can be read by the standard utility. (Thanks to JZ for clarifying this one for me.) Action: Qualify at head of section that "shall" means "must" for STDIN. (Or consider discarding the shall/must distinction; this sort of dual meaning is a problem that is avoided by avoiding the distinction.) "In this section, when referring to STDIN, the word 'shall' is to be read as 'must'." _____________________________________________________________________________ Editorial Enhancement Request Number 31 donnte@microsoft.com BUG in XBD (rdvk# 30) [DT-XBD-31] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 162 Line: 5418 Section: 7.3 Problem: "The hour may be a single digit" doesn't quite clearly state what is intended, and is a bit of a nonsequeteur. How about rewriting the whole paragraph as below. Also, "shall be required" is a bit redundant: shall is imperative anyway, so it's "requiring that something be required". In this case, it shouldn't be shall anyway, as its a requirement on input (the user side), unless you're intending to require a diagnostic, which this doesn't quite say. This also trips another problem: there are features of the standard where both "shall" and "must" apply: if the implementation provides it as a default (such as the default TZ) it's a "shall"; if the user provides it (as in a specific user's TZ) it's a "must". See the change to line 34 for new text for "must". (Note also that the use of "must" on line 5414 is not conforming to the definition of "must" in this standard; the user isn't required to do anything here, it just describes a situation.) Action: Replace with: offset Indicates the value which when added to the local time is the corresponding Coordinated Universal time. The offset has the form: [-|+]hh[:mm[:ss]] The hour (hh) must be present; the minutes (mm) and (ss) are optional. The hour, and if present, minutes and seconds: - can be represented as either one or two digits - are interpreted as decimal numbers. The hour must be between zero and 24, and the minutes and seconds between zero and 59. Use of values outside these ranges is undefined. If the optional '-' is present, the timezone is interpreted as east of the Prime Meridian, otherwise it is interpreted as west (and an optional '+' can be provided). The offset after std must be present. If no offset follows dst, the alternative time is assumed to be one hour ahead of standard time. _____________________________________________________________________________ Editorial Enhancement Request Number 32 donnte@microsoft.com BUG in XBD (rdvk# 31) [DT-XBD-32] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 168 Line: 5563 Section: 8.2 Problem: "shall". Here this is not a requirement on either the implementor or the user, but rather it is either a requirement on the standard itself, or (more rationally) it is simply descriptive of the standard. Action: "shall apply" -> apply. _____________________________________________________________________________ Editorial Enhancement Request Number 33 donnte@microsoft.com BUG in XBD (rdvk# 32) [DT-XBD-33] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept, although note that the text is a duplicate of POSIX.2 clause 2.8.5.1 _____________________________________________________________________________ Page: 181 Line: 6054 Section: 8.5.1 Problem: "shall be as described". I'm not quite sure who is being required to do what here, but it appears that it's a requirement on the standard itself, which to me would rather make it simply "are" Action: "shall be as" -> "are". _____________________________________________________________________________ Objection Enhancement Request Number 34 donnte@microsoft.com BUG in XBD (rdvk# 33) [DT-XBD-34] Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 203 Line: 6862 Section: 11.1 Problem: The text starting with 6862 appears to be an XSI extension, and therefore should be in grey. So should the table on the next page. Action: Add shading. _____________________________________________________________________________ Objection Enhancement Request Number 35 donnte@microsoft.com BUG in XBD (rdvk# 34) Thu Nov 11, 4:10pm -0800 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 {In 6978- we should remove the sentence "Instances of .... option-arguments", since the LEGACY stuff has gone.} _____________________________________________________________________________ Page: 206 Line: 6970, Section: 11.1 [DT-XBD-35] Problem: The paragraphs beginning at each of the lines listed above are rationale and explanatory, and do not make requirements in themselves. The text at 6970 appears in the -1990 standard, and really should have been rationale or a note (I'd prefer a note). (There's no requirement being made on anyone, so it doesn't serve in normative text.) Action: Move to rationale (or in the cases of 6970 and 6973, notes.) _____________________________________________________________________________ objection Enhancement Request Number 36 prindle@voicenet.com Bug in XBD (rdvk# 36) [prindle.xbd-1] Mon Nov 22, 1:52pm -0500 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: accept _____________________________________________________________________________ Page: 269 Line: 8956 Section: Problem: The symbol PTHREAD_MUTEX_INITIALIZER is incorrectly shaded XSI and appears out of alphabetical order. Action: Remove shading, and collate into alphabetical order (move up one line). ------------------------------------------------------------------------------- _____________________________________________________________________________ objection Enhancement Request Number 37 prindle@voicenet.com Bug in XBD (rdvk# 37) [prindle.xbd-2] Mon Nov 22, 1:52pm -0500 _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Austin/36 _____________________________________________________________________________ Page: 269 Line: 8973 Section: Problem: To support prindle.xsh-1, pthread_atfork() needs to be prototyped in this header as well as . Action: Include the same prototype for pthread_atfork() as is currently in here also. -------------------------------------------------------------------------------