Document Number: AUSTIN/107r2 Title: XBDft Aardvark Change Request Report (final) Revision Date: 2002-06-21 Source: Andrew Josey, Chair Action: for review This report contains the draft dispositions of the aardvark comments submitted against the XBD final text. Aardvark Summary Table ______________________ ERN 1 Accept ERN 2 Reject ERN 3 Accept as marked ERN 4 Reject ERN 5 Reject ERN 6 Reject ERN 7 Reject ERN 8 Reject ERN 9 Accept as marked ERN 10 Reject ERN 11 Accept as marked ERN 12 Accept ERN 13 Accept as marked ERN 14 Accept ERN 15 Accept as marked ERN 16 Accept ERN 17 Accept as marked ERN 18 Accept as marked ERN 19 Accept as marked ERN 20 Accept ERN 21 Accept as marked ERN 22 Accept ERN 23 Accept ERN 24 Accept ERN 25 Accept ERN 26 Accept ERN 27 Accept ERN 28 Accept ERN 29 Accept ERN 30 Accept ERN 31 Accept ERN 32 Accept ERN 33 Accept ERN 34 Accept as marked ERN 35 Reject ERN 36 Accept ERN 37 Accept as marked ERN 38 Accept as marked ERN 39 Reject ERN 40 Accept as marked ERN 41 Accept ERN 42 Accept ERN 43 Reject _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 gwc@opengroup.org Defect in XBD 1.1 Scope (rdvk# 12) [gwc scope legacy list] Tue, 5 Mar 2002 11:24:43 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2 Line: 69 Section: 1.1 Defect code : 1. Error Problem: The list of XSH5 legacy interfaces is missing regex(), ttyslot() and valloc(). These were in the Austin Group scope document (Austin/9r6) so it looks like this was just a simple editorial omission. Action: After "regcmp()," insert "regex(),". After "step()," insert "ttyslot(), valloc(),". [Ed recommendation: Accept This should go into TC1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 mgh@unican.es Defect in XBD (rdvk# 33) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 8 Line: 306-321 Section: 1.5.1 Problem: The option codes MC1 and MC2 are not used. For example, MC1 seems to have been created for posix_madvise(), but it is not used there The same problem appears in the "codes" sections in XSH and XSI. Action: Either delete codes MC1 and MC2 or use them where appropriate, in XBD, XSI, and XSH [Ed recommendation: Reject The codes MC1 and MC2 are used on the man page] Ed note: The code at the top of posix_madvise() could be recoded as MC1, however as written it is not technically incorrect. Add to markup copy. _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 mgh@unican.es Defect in XBD (rdvk# 34) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the suggested change as below, plus also perform this change on unistd.h p 401 l 14133 _____________________________________________________________________________ Page: 13 Line: 537 Section: 2.1.3 Problem: The thread stack size option is called "thread stack address size", but should be called "thread stack size attribute". The "address" itself has no size. Action: Change the name of the option to the correct "thread stack size attribute". Check also in other parts of the document. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 mgh@unican.es Defect in XBD (rdvk# 32) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 16 Line: 649-716 Section: 2.1.3 Problem: The standard does not say which functions fall under the XOPEN_SHM option. The symbol is specified under , but not described in section 2.1.3 This option is called out by the new POSIX.13 realtime profiles and therefore the specification of which functions fall under the option is necessary. Action: Specify the XOPEN_SHM symbol in section 2.1.3, and specify the list of functions that fall under the corresponding option. This could be a list in section 2.1.3.1 [Ed recommendation: Reject, firstly 2.1.3 is for POSIX Conformance, and this is a mandatory XSI symbol required to support previous versions of the XSI specifications. Secondly profiling considerations are in the rationale and not in the normative text, and that was intentional to avoid this situation whereby profiling changes continue to happen. We do not want to be continually updating this standard for support of the Profiles, see 2.1.5.1 for the enablers] _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 mgh@unican.es Defect in XBD (rdvk# 31) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 16 Line: 649-716 Section: 2.1.3 Problem: The standard does not say which functions fall under the option: Reader/Writer locks (with symbol _POSIX_READER_WRITER_LOCKS) The symbol is specified under , but not described in section 2.1.3 Although this option is mandatory in the new POSIX.1 standard under the threads option, it is called out by the new POSIX.13 realtime profiles and therefore the specification of which functions fall under the option is necessary. Action: Specify the _POSIX_READER_WRITER_LOCKS symbol in section 2.1.3, and specify the list of functions that fall under the corresponding option. This could be a list in section 2.1.3.1 [Ed recommendation: Reject, firstly 2.1.3 is for POSIX Conformance and the symbols listed therein are options or where some optionality is allowable. For this standard _POSIX_READER_WRITER_LOCKS are manatory. Secondly profiling considerations are in Part E of the rationale. We do not want to be continually updating this standard for support of the Profiles, see 2.1.5.1 for the enablers] _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 mgh@unican.es Defect in XBD (rdvk# 30) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 16 Line: 649-716 Section: 2.1.3 Problem: The standard does not say which functions fall under the option: Regular expression functions (with symbol _POSIX_REGEXP) The symbol is specified under , but not described in section 2.1.3 Although this option is mandatory in the new POSIX.1 standard, it is called out by the new POSIX.13 realtime profiles and therefore the specification of which functions fall under the option is necessary. Action: Specify the _POSIX_REGEXP symbol in section 2.1.3, and specify the list of functions that fall under the Regular expressions option. This could be a list in section 2.1.3.1 [Ed recommendation: Reject This symbol is described in Part E of the rationale. See discussion in 2.1.5.1 on subprofiling] _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 mgh@unican.es Defect in XBD (rdvk# 29) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 16 Line: 669-672 Section: 2.1.3 Problem: The standard does not say which functions fall under the option: Job Control (with symbol _POSIX_JOB_CONTROL) Although this option is mandatory in the new POSIX.1 standard, it is called out by the POSIX.13 realtime profiles and therefore the specification of which functions fall under the option is necessary. Action: Specify the list of functions that fall under the Job Control option. This could be a list in section 2.1.3.1 [Ed recommendation: Reject This symbol is described in Part E of the rationale. See discussion in 2.1.5.1 on subprofiling] _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 mgh@unican.es Defect in XBD (rdvk# 36) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 23 Line: 925-960 Section: 2.1.3 Problem: There is no symbol to represent the Advanced Realtime option. Although this is not strictly necessary because the advanced realtime option is just a collection of other options, it seems that for consistency with other option groups a symbol should be defined Action: Add a new symbol for the Advanced Realtime option group [Ed recommendation: Reject The Base Working Group felt this unnecessary to generate yet another symbol. ] _____________________________________________________________________________ COMMENT Enhancement Request Number 9 terekhov@de.ibm.com Defect in XBD 4.10 Memory Synchronization (rdvk# 26) {3} Sat, 23 Mar 2002 08:40:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Our advice is as follows. Hardware that does not allow atomic accesses cannot have a POSIX implementation on it. We propose no changes to the standard. Please note that the committee is not required to give advice, this sort of topic may be better to be discussed initially on the group reflector prior to any aardvark submission. _____________________________________________________________________________ Page: 100 Line: 3115 Section: 4.10 Problem: Defect code : 3. Clarification required dvv@dvv.ru (Dima Volodin) wrote: .... The standard doesn't provide any definition on memory location [POSIX is a C API, so it must be done in C terms?]. Also, as per standard C rules, access to one memory location [byte?] shouldn't have any effect on a different memory location. POSIX doesn't seem to address this issue, so the assumption is that the usual C rules apply to multi-threaded programs. On the other hand, the established industry practices are such that there is no guarantee of integrity of certain memory locations when modification of some "closely residing" memory locations is performed. The standard either has to clarify that access to distinct memory locations doesn't have to be locked [which, I hope, we all understand, is not a feasible solution] or incorporate current practices in its wording providing users with means to guarantee data integrity of distinct memory locations. "Please advise." --- http://groups.google.com/groups?hl=en&selm=3B0CEA34.845E7AFF%40compaq.com Dave Butenhof (David.Butenhof@compaq.com) wrote: .... POSIX says you cannot have multiple threads using "a memory location" without explicit synchronization. POSIX does not claim to know, nor try to specify, what constitutes "a memory location" or access to it, across all possible system architectures. On systems that don't use atomic byte access instructions, your program is in violation of the rules. Action: "Please advise." ;-) _____________________________________________________________________________ COMMENT Enhancement Request Number 10 terekhov@de.ibm.com Defect in XBD 4.10 Memory Synchronization (rdvk# 27) {2} Sat, 23 Mar 2002 08:18:58 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The group felt that this was not sufficient grounds for a change in the standard. Leaving these functions on the list makes the requirements explicit. _____________________________________________________________________________ Page: 100 Line: 3120-3128 Section: 4.10 Problem: Defect code : 3. Clarification required I think that pthread_cond_signal() and pthread_cond_broadcast() should be REMOVED from the list of functions that synchronize memory with respect to other threads because IMO applications just cannot have any useful dependencies on pthread_cond_signal() and/or pthread_cond_broadcast() w.r.t memory synchronization/ visibility. The predicate is fully protected by the associated mutex with lock/unlock calls plus pthread_cond_wait() and pthread_cond_timedwait() providing execution and memory synchronization to the full extent. Action: Remove pthread_cond_signal() and pthread_cond_broadcast() from the list of functions that synchronize memory with respect to other threads. _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 terekhov@de.ibm.com Defect in XBD 4.10 Memory Synchronization (rdvk# 28) {1} Sat, 23 Mar 2002 08:06:09 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a new paragraph in section 4.10 before l 3129, (this is a candidate for TC1): pthread_once() synchronizes memory for the first call in each thread for a given pthread_once_t object (ed note this may need some word smithing) _____________________________________________________________________________ Page: 100 Line: 3120-3128 Section: 4.10 Problem: Defect code : 2. Omission pthread_once() is missing from the list of functions that synchronize memory with respect to other threads. Action: Add pthread_once() to the list of functions that synchronize memory with respect to other threads. _____________________________________________________________________________ COMMENT Enhancement Request Number 12 ajosey@opengroup.org Defect in XBD LC_MONETARY (rdvk# 13) {aj.4217.interp} Thu, 7 Mar 2002 06:45:00 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 140 Line: 4787 Section: LC_MONETARY Problem: Defect code : 3. Clarification required Is an implementation that limits the allowed int_currency_symbol in the LC_MONETARY locale category to a subset of those defined in ISO 4217 POSIX compliant? For example an implementation that limits the allowed int_currency_symbol to just those valid currencies for cash transactions. Action: The standard is clear, such an implementation is non-conforming. POSIX states that the int_currency_symbol can take any of the values defined in ISO 4217 and does not define a subset of the symbols. All currency symbols defined in ISO 4217 shall be accepted by POSIX conforming implementations. [Ed recommendation: Accept This should become an interpretation of IEEE Std 1003.1-2001] ________________________________________________________________________________ OBJECTION Enhancement Request Number 13 gwc@opengroup.org Defect in XBD locale definition/grammar (rdvk# 9) [gwc POSIX LC_MONETARY values] Fri, 15 Feb 2002 10:35:08 +0000 ________________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the changes below, plus also These are the changes needed for the table on page 143 in XBD: Add before line 4897: int_p_cs_precedes -- N/A {CHAR_MAX} -1 int_p_sep_by_space -- N/A {CHAR_MAX} -1 int_n_cs_precedes -- N/A {CHAR_MAX} -1 int_n_sep_by_space -- N/A {CHAR_MAX} -1 int_p_sign_posn -- N/A {CHAR_MAX} -1 int_n_sign_posn -- N/A {CHAR_MAX} -1 ________________________________________________________________________________ Page: 142 Line: 4882 Section: 7.3.3.1 Problem: Defect code : 1. Error The new LC_MONETARY int_[np]_* values are missing from the POSIX locale definition. Action: After line 4882 add: int_p_cs_precedes -1 int_p_sep_by_space -1 int_n_cs_precedes -1 int_n_sep_by_space -1 int_p_sign_posn -1 int_n_sign_posn -1 _____________________________________________________________________________ OBJECTION Enhancement Request Number 14 gwc@opengroup.org Defect in XBD locale definition/grammar (rdvk# 10) [gwc locale grammar] Fri, 15 Feb 2002 10:35:08 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 156 Line: 5477 Section: 7.4.2 Problem: Defect code : 1. Error The new int_[np]_* keywords are missing from the locale grammar. Action: After line 5477 add: | 'int_p_cs_precedes' | 'int_p_sep_by_space' | 'int_n_cs_precedes' | 'int_n_sep_by_space' | 'int_p_sign_posn' | 'int_n_sign_posn' _____________________________________________________________________________ COMMENT Enhancement Request Number 15 lennox@cs.columbia.edu TZ (rdvk# 2) {3} Wed, 16 Jan 2002 02:08:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (candidate for TC1) Add exec to the SEE ALSO entries setenv() and putenv() Add to the APPLICATION USAGE for setenv() and putenv() See exec for restrictions on changing the environment in multithreaded applications. _____________________________________________________________________________ Page: 164 Line: 5795 Section: 8.3 Problem: Defect code : 2. Omission (This is an update for Posix 2001 of part 3 of defect report #135 for 1003.1:1996.) It is unclear whether it is safe for a multi-threaded program to change the value of the TZ environment variable within one thread, while using the functions ctime(), ctime_r(), localtime(), localtime_r(), strftime(), and mktime() within other threads. Action: Add, somewhere, the following text. It's not clear whether this should accompany the definition of TZ, or the definition of the relevant functions. If {_POSIX_THREAD_SAFE_FUNCTIONS} is defined: The tzset(), ctime(), ctime_r(), localtime(), localtime_r(), strftime(), and mktime() functions shall be thread-safe with respect to the interpretation of TZ and the setting of tzname, if TZ is changed. In the absence of synchronization information, which value of TZ applies to any call to ctime(), ctime_r(), localtime(), localtime_r(), strftime(), and mktime() is undefined. ctime() and localtime() need not be thread-safe with respect to their returned data. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 16 lennox@cs.columbia.edu TZ (rdvk# 3) {1} Wed, 16 Jan 2002 01:36:38 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 164 Line: 5797 Section: 8.3 Problem: Defect code : 1. Error The description of the TZ environment variable omits the names of some functions which are defined as using it, specifically the thread-safe variants of the ctime() and localtime() functions. The original text is: The contents of the environment variable named TZ shall be used by the ctime(), localtime(), strftime(), and mktime() functions.... This list ought to also include the functions ctime_r() and localtime_r(). They should, of course, be highlighted, with "TSF" marked in the margin. Action: Change the list "ctime(), localtime(), strftime(), and mktime()" to "ctime(), localtime(), strftime(), mktime(), [begin highlighting]ctime_r(), and localtime_r()[end highlighting]". Add "TSF" in the margin next to the highlighted text. _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 eggert@twinsun.com Defect in XBD Regular Expressions (rdvk# 43) {eggert20020430a} Wed, 1 May 2002 00:17:32 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being deferred to a new subgroup. _____________________________________________________________________________ Page: 167 Line: 5889 Section: Regular Problem: Defect code : 3. Clarification required The Regular Expressions section does not reflect the resolutions of the June 1995 POSIX RE experts meeting as reported by David Korn in Action: Adopt the interpretations of the June 1995 POSIX RE experts meeting as referenced above, with the exceptions of the I18N interpretations (i.e, those interpretations starting with Interp #41, Part 7 and continuing to the end of the meeting notes). The I18N interpretations are now somewhat obsolete, since that part of the standard was changed in POSIX 1003.1-2001. However, the other interpretations are to parts of the standard that have not changed, so they are still relevant. [Ed recommendation: None (From X-Mailing-List: austin-group-l:archive/latest/3971) In the copy below, I have edited the page, section, and line numbers so that they refer to the 2001 final text, and (as I mentioned earlier) I am omitting the I18N-related actions. Also, for ease of reference I am placing an "ACTION:" annotation at the start of each recommended action. These are the only changes that I made. o Interp #43, Part 15. To which match is a backreference to a duplicated subexpression bound? ACTION: To resolve Interp #43, Part 15, add on XBD page 172, Section 9.3.6(3) after line 6109, "When a referenced subexpression does not match any string (not even the empty string), the backreference expression fails to match. When subexpressions are nested, the substrings matching them are similarly nested. When a contained subexpression fails to participate in the last match of its containing subexpression, backreferences to the contained subexpression fail to match." For example \(a*\(b\)*\)\{2\}\2 fails to match ba o Interp #43, Part 12. Can a duplicated subexpression match the null string? If so, will the duplication be repeated until the expression does match the null string? There was a consensus that applying a duplicator to a RE that could match the empty string should be unspecified. However, if specified, the specification in P1003.1-2001 is incorrect and should be changed. ACTION: On XBD page 172, Section 9.3.6, change line 6127 to, "When a subexpression or a backreference is repeated by an asterisk(*) or an interval expression, the subexpression shall not match a null". Also, change XBD page 175 section 9.4.6 lines 6239-6241 to, "When an ERE enclosed in parentheses is repeated by a *, ?, +, or an interval expression, the ERE enclosed in parentheses shall not match the empty string unless it is necessary to satisfy the exact or minimum number of occurrences for the + or interval expression." o Interp #43, Part 14. What does it mean by the left- to-right order in a match on line 5908? For example, with pattern ((..)*(.....)*)* and string xxxxx, what should \1 be? Lines 5911 and 5908 would give contradictory answers. ACTION: To resolve Interp #43, Part 14, add on XBD page 167, Section 9.1 after sentence ending on line 5908, "An enclosed subpattern is deemed to be to the right of an enclosing pattern." On XBD page 172, Section 9.3.6, change lines 6090-6091 to "The following rules, in conjunction with the general requirements of Sections 9.1 and 9.2, shall be used to construct BREs matching multiple characters". On XBD page 172, Section 9.3.6(2), line 6095 replace "whatever" with "any string". On XBD page 175, Section 9.4.6, change lines 6205-6206 to "The following rules, in conjunction with the general requirements of Sections 9.1 and 9.2, shall be used to construct EREs matching multiple characters". On XBD page 175, Section 9.4.6(1), line 6209 replace "whatever" with "any string". o Interp #44. There was unanimous agreement that the error numbers must be unique. o Interp #45. Current interp and change OK. o Interp #60. This needs to be fixed in .1. o Interp #73. Current interp and change OK. o Interp #82. The current interpretation is incorrect. In section 9.3.6(3), lines 6098-6099 the standard says that a backreference matches a "string of characters". Therefore, the standard requires that the expression \(^b\)\1 must match the first two characters of bbbb. o Interp #85. Agreement except that dumping core should not be allowed for bad expressions. ACTION: Therefore on XBD section 9 lines 5927, 5942, 5970, 5982, 6075, 6125, 6171, 6180, 6185, 6193, 6238, 6468, undefined should be changed to unspecified. o Interp #86. Current interp and change OK. o Interp #88. Wording for interp #45, part 15 should take care of this. o Interp #125. What is the meaning of BRE\{0,0\}? The current wording leaves the behavior unspecified. ACTION: On XBD page 172, Section 9.3.6(4), add after end of sentence on line 6112, "Zero occurrences of a BRE match the empty string". On XBD page 175, Section 9.4.6(3), add after end of sentence on line 6219, "Zero occurrences of an ERE match the empty string". Note that this added sentence must also apply to parts (3), (4) and (5). o Doug #6. Does case folding apply to backreferences? ACTION: On XBD page 172, Section 9.3.6(3), add after line 6109, "When pattern matching is being performed without regard to case, the backreference match will occur without regard to case." ACTION: Also, on XBD page 170, Section 9.3.5(3), add after end of sentence on line 6022, "Whenever pattern matching is being performed without regard to case, each character or collating element shall be deemed to stand for itself and all its case counterparts." On XBD page 168, Section 9.2, line 5954 change "counterpart" to "counterparts". It wasn't clear whether there is such a thing as upper and lower multi-character collating elements. _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 gsf@research.att.com BUG in XBD6 (rdvk# 39) omission [att.dgk-1] Tue, 30 Apr 2002 16:32:37 -0400 (EDT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being deferred to a new subgroup. _____________________________________________________________________________ Page: 167 Line: 5889 Section: 9.1 Problem: The standard uses the term "subpattern" without providing a definition. Different assumptions about the meaning of this term have lead to conflicting interpretations of the definition of "matched" starting at line 5907. A formal definition for "subpattern" can resolve the conflict. Furthermore, a formal definition for "subexpression" can emphasize the current implied distinction between "subpattern" and "subexpression". The consequence of the Action: below is that it gives unambiguous meaning to the paragraph starting at line 5907: "Consistent with the whole match being the longest of the leftmost matches, each subpattern, from left to right, shall match the longest possible string." Note that this definition implies that a pattern is the concatenation of all of its subpatterns from left to right. Action: Add these definitions after line 5889. subpattern A part of a pattern corresponding to the ERE grammar nonterminal ERE_expression or the BRE grammar nonterminal simple_RE. The the longest applicable grammar production shall apply in the recognition of ERE_expression and simple_RE. For example, the ERE "(ab)c*" contains two subpatterns, "(ab)" and "c*". The ERE alternation rule (9.4.7) shall be applied before subpatterns are identified. subexpression An ERE subpattern of the form "'(' extended_reg_exp ')'" or a BRE subpattern of the form "Back_open_paren RE_expression Back_close_paren". For example, the ERE "((a)(b))(c*)" contains two subexpressions, "((a)(b))" and "(c*)". A subexpression may contain other subexpressions; this is referred to as nesting. ---Additional text added 7 May 2002 supporting documentation for BUG IN XBD [att.dgk-1] Glenn Fowler Andrew Hume David Korn AT&T Labs Research Florham Park, NJ Assume the following definitions from [att.dgk-1]: subpattern A part of a pattern corresponding to the ERE grammar nonterminal ERE_expression or the BRE grammar nonterminal simple_RE. The the longest applicable grammar production shall apply in the recognition of ERE_expression and simple_RE. For example, the ERE "(ab)c*" contains two subpatterns, "(ab)" and "c*". The ERE alternation rule (9.4.7) shall be applied before subpatterns are identified. subexpression An ERE subpattern of the form "'(' extended_reg_exp ')'" or a BRE subpattern of the form "Back_open_paren RE_expression Back_close_paren". For example, the ERE "((a)(b))(c*)" contains two subexpressions, "((a)(b))" and "(c*)". A subexpression may contain other subexpressions; this is referred to as nesting. General support for change: The omission of a definition for "subpattern" was clearly a mistake. The proposal defines a subpattern as a matching primitive. The standard provides two descriptions of regular expressions: grammatical and the textual. The grammar specifies the syntax. It can be used to recognize valid regular expressions (a reductive process) or in can be used to build valid regular expressions from primitives (a constructive process). What are the primitives? The primitives are the lexical items that remain after the "constructive" operators are removed. The constructive operators are alternation ('|'), concatenation (invisible), and the duplication operators '*', '+', '?' and '{' range '}'. After collapsing intermediate nonterminals for all but bracket_expression we end up with: The BRE primitives are: ORD_CHAR QUOTED_CHAR '.' bracket_expression Back_open_paren RE_expression Back_close_paren BACKREF The ERE primitives are: ORD_CHAR QUOTED_CHAR '.' bracket_expression '^' '$' '(' extended_reg_exp ')' Using the grammar convention (the grammars in the standard are yacc-like) that the longest production applies, we can argue that a BRE primitive includes any RE_dupl_symbol appendages and an ERE primitive includes any ERE_dupl_symbol appendages. The text describes in detail how primitives match under "Basic Regular Expressions" and "Extended Regular Expressions"; there is a subclause for each of the BRE and ERE primitives listed above. The text then describes how to construct BREs and EREs matching multiple characters using concatenation of primitives described in the previous clauses: "The concatenation of BREs shall match the concatenation of the strings matched by each component of the BRE." "A concatenation of EREs shall match the concatenation of the character sequences matched by each component of the ERE." We can safely assume that "component" means "primitive" here; "component" cannot mean "a concatenation of primitives", because that would be a recursive reference to the word "concatenation" in a clause that describes the semantics of "concatenation". These clauses form the constructive description of concatenation. The corresponding reductive description is found in the definition of "matched": "Consistent with the whole match being the longest of the leftmost matches, each subpattern, from left to right, shall match the longest possible string." The constructive description builds up a pattern by "components" and the reductive description breaks down a pattern by "subpattern". This proposal simply claims that "components" and "subpatterns" are synonymous with regular expression primitives. Also, given the definition of subexpression, the use of the term "parenthesized subexpression" is redundant and possibly confusing. There are portions of the existing text that clearly refer to "subexpression" as a parenthesized part of a pattern. "parenthesized subexpression" can stay; the definition removes any doubt to its meaning. When placed in order the rules and rationale for regular expression matching clearly model a recursive descent parser: page 176 line 6240 "the expression alternation rule" Two EREs separated by the special character vertical-line ('|') shall match a string that is matched by either. page 167 line 5898 "the leftmost longest match rule" The search for a matching sequence starts at the beginning of a string and stops when the first sequence matching the expression is found, where first is defined to mean ``begins earliest in the string''. If the pattern permits a variable number of matching characters and thus there is more than one such sequence starting at that point, the longest such sequence is matched. page 167 line 5905 "the left to right subpattern rule" Consistent with the whole match being the longest of the leftmost matches, each subpattern, from left to right, shall match the longest possible string. page 3350 line 2358 "the subexpression recursion rationale" It is possible to determine what strings correspond to subexpressions by recursively applying the leftmost longest rule to each subexpression, but only with the proviso that the overall match is leftmost longest. Conceptually, the implementation must examine every possible match and among those that yield the leftmost longest total matches, pick the one that does the longest match for the leftmost subexpression, and so on. The following pseudo code for a recursive descent traversal of an extended_reg_exp show that the rules visit all and the same portions of a subpattern as would have been identified by a classical parse tree; indeed this function (and the rules) could *build* a parse tree: 1: traverse(extended_reg_exp) { 2: for each ERE_branch in extended_reg_exp 3: for each ERE_expression in ERE_branch from left to right 4: if ERE_expression == '(' extended_reg_exp' ')' 5: traverse(extended_reg_exp') 6:} Here are the statement numbers labeled by the rule/rationale applied: 2: "the expression alternation rule" 4: "the left to right subpattern rule" 5: "the subexpression recursion rationale" If traverse() were changed to match() then there would be an else after 5: that would match the ERE_expression in hand to the current position in the subject string using the "ERE matching a single character" rules from the text. This is where the left-associative interpretation has some explaining to do: at 3: left-associative might hand out an ERE_branch instead of an ERE_expression; but how do you match an ERE_branch against a subject string? If you say "for each ERE_expression in ERE_branch" then why not let line 3: do it? Now a FAQ style discourse for the questions some readers must have by this point. Q: You conclude that RE matching is right-associative, but isn't the grammar production for ERE_branch left-associative? A: This is a common misconception. That production is left-recursive, a subtle distinction with profound consequences. left-recursion is a grammatical tool that specifies ordered lists; neither left-associativity nor right-associativity is implied. Consider the C and awk standard grammars. Both require additional non-grammar text and/or tables to specify operator associativity. The purpose of a grammar in POSIX is to specifiy/recognize complex input syntax; semantic descriptions, including those for left/right-associativty, are reserved for the text, and that's exactly what the "the left to right subpattern rule" does. Q: I'm still not convinced. A: OK. Consider the following grammar productions for a number, defined as a string of digits: l-number : DIGIT | l-number DIGIT ; r-number : DIGIT | DIGIT r-number ; l-number is a left-recursive production and r-number is a right recursive production. If you were given a number you wouldn't be able to tell if it were constructed by l-number or r-number, you would just have a concatenated string of digits. But that's ok because what really matters for a number is the number of digits and the left-to-right order of the digits; the number and order are the same for l-number or r-number. So, DIGIT concatenation in l/r-number is exactly analgous to ERE_expression concatenation in ERE_branch. Q: How about beyond a reasonable doubt ...? A: Left to right examination of a list of items is the exact definition of right-associativity. The only way to refute this is to redefine what an "item" is. If an "item" is anything but the primitive list element then one could imagine definitions suitably constructed to support any claim; we are witness to this: by defining the "item" to be "ERE_branch or ERE_expression" you can claim left associativity. But where is the justification for mixing ERE_expression primitives with ERE_branch grammar artifacts? It certainly doesn't resonate with the l/r-number analogy. And the text goes through great pains in describing how to match ERE_expression; it doesn't make sense to generate ERE_branch "left-associative-subpatterns" at a step in in the matching that is supposed to to apply the matching primitives. Q: What about the "algebraic regexp" properties of the left-associative interpretation posted on the austin-group-l mailing list; doesn't a right-associative implementation force us to give up some nice results? A: A good case is presented for properties induced by a left-associative interpretation. What isn't mentioned is that left-associative matching comes at a price -- the subexpression leftmost-longest rationale is thrown out: page 3350 line 2362-2364 Conceptually, the implementation must examine every possible match and among those that yield the leftmost longest total matches, pick the one that does the longest match for the leftmost subexpression, and so on. The rationale clearly states, even with the old implied definition for subexpression (that parenthesized thing), that, just as the overall match is leftmost-longest, so are the matches for all subexpressions from left to right. With left-associativity all you can say about a match is "the overall match is leftmost longest"; some subexpressions may be shortest, some may be longest, some may be whatever. To illustrate what is happening, suppose '<' and '>' are new ERE special characters that group like '(' and ')' but do not affect backreference numbering or regexec() nmatch[] indices (this is a thought experiment, not a proposal). All patterns are matched against the subject string weeknights: ASSOCIATIVITY PATTERN MATCH 1: right (wee|week)(night|knights) (wee)(knights) 2: right (wee|week)(night|knights)(s*) (week)(night)(s) 3: left (wee|week)(night|knights) (wee)(knights) 4: left <(wee|week)(night|knights)>(s*) (wee)(knights)() Left associativity still follows the rules laid out in the text, but as applied to the imposed left-associativity, shown by the invisible grouping '<' ... '>'. What this means is that the invisible groups are matched leftmost longest, even though they are an artifact that can't be referenced. 4: is clearly in conflict with the subexpression leftmost longest rationale (not so for 2:). The '<' ... '>' illustrates the grammar artifact mentioned in the previous question. It also shows an "everything but the last primitive" definition for subpattern. Q: So what? A: If, under left-associative matching, leftmost longest cannot be asserted for each subexpression from left to right, then there would be no way to define a leftmost shortest (or minimal) match extension to the standard (a few regex implementations support this already.) Extensions for RE negation would suffer similarly (yes, there is at least one regex implementations with negation.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 eggert@twinsun.com Defect in XBD 9.1 (rdvk# 42) {eggert20020430b} Wed, 1 May 2002 00:55:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is being deferred to a new subgroup. _____________________________________________________________________________ Page: 167 Line: 5889 Section: 9.1 Problem: Defect code : 2. Omission The standard uses the term "subpattern" without providing a definition. Different assumptions about the meaning of this term have lead to conflicting interpretations of the definition of "matched" starting at line 5907. A formal definition for "subpattern" can resolve the conflict. This is part of the problem mentioned by Glenn Fowler and David Korn in an earlier aardvark today but with a different action for the definition of "subpattern". This action differs in that it uses the left-associative rule specified by the POSIX grammar for regular expressions, instead of the right-associative rule that is equivalent to the behavior proposed in the earlier aardvark. Action: Add this definition after line 5889. subpattern A pattern that is syntactically part of another pattern as indicated by the grammar. For example, the ERE /ab(cd)*/ has the subpatterns /ab/, /a/, /b/, /(cd)*/, /(cd)/, /cd/, /c/, and /d/. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 20 ajosey@opengroup.org Defect in XBD glob.h (rdvk# 4) {tc1-3} Thu, 24 Jan 2002 13:40:52 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 236 Line: 8313 Section: glob.h Problem: Defect code : 1. Error (page and line numbers are for the ft [finaltext] document) When the restrict type qualifier was added to the glob() prototype declaration in D4, it was applied to a function pointer argument; per ISO/IEC 9899:1999 such a pointer type shall not be restrict-qualified. (The definition on XSH page 573 line 18778-18779 is correct) Action: Change L8313-8314 from: int glob(const char *restrict, int, int (*restrict)(const char *, int), glob_t *restrict); to: int glob(const char *restrict, int, int (*)(const char *, int), glob_t *restrict); [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 21 ajosey@opengroup.org Defect in XBD langinfo.h (rdvk# 20) {nl_langinfo_grey_area} Tue, 19 Mar 2002 17:39:55 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Propose for TC1 change to xbd 244 l8586 Local currency symbol, preceded by - if the symbol should appear before the value, + if the symbol should appear after the value, or . if the symbol should replace the radix character. If the local currency symbol is the empty string implementations may return the empty string (""). Rationale This change is being made to accomodate historic practise. This is a application visible change. Implementations may choose either behavior. Applications should check for the empty string . _____________________________________________________________________________ Page: 244 Line: 8586 Section: langinfo.h Problem: Defect code : 3. Clarification required Historically nl_langinfo(CRNCYSTR) when the language binding is C (or POSIX) has returned the value "" (an empty string) . XPG3 said that CRNCYSTR was an empty string for the C locale (XPG3 Vol 3 Page 60). This is existing behavior for many systems, and has been tested it this way for 13 years since XPG3, so based on existing behaiour this would appear to be intended. The langinfo.h text describing CRNCYSTR states CRNCYSTR (LC_MONETARY) Local currency symbol, preceded by - if the symbol should appear before the value, + if the symbol should appear after the value, or . if the symbol should replace the radix character. This takes into account ANSI C (later ISO C) which split parts of the currency information into separate parts of the struct lconv. A grey area appears to be in the definition when there is no currency symbol. If there is none is there still a requirement to return a -,+ or "." , and if so which one? Existing behavior points to an empty string being returned on most systems, but the specification is unclear. Action: Change from: Local currency symbol, preceded by - if the symbol should appear before the value, + if the symbol should appear after the value, or . if the symbol should replace the radix character. to: Local currency symbol, preceded by - if the symbol should appear before the value, + if the symbol should appear after the value, or . if the symbol should replace the radix character.Otherwise if there is no currency symbol return the empty string (""). [Ed recommendation: None This appears to be a grey area and we should allow both behaviors for this issue of the specification. Do we want to go a particular way in the future, or say that it could be either "" or "-"? ] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 22 ajosey@opengroup.org Defect in XBD limits.h (rdvk# 11) {aj._POSIX_CHILD_MAX} Fri, 1 Mar 2002 12:02:34 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 253 Line: 8923 Section: limits.h Problem: Defect code : 1. Error The value of CHILD_MAX is defined to be _POSIX_CHILD_MAX which is 6. This should be 25 which is the FIPS mandated value (we explicitly decide to align with the FIPS as part of the project) In D4 we had the value explicitly for CHILD_MAX to be 25. In D5 we updated this to _POSIX_CHILD_MAX. >From the minutes for the October 2000 meeting "REVIEWERS NOTES: Page 288 change the non _POSIX_ limits to use the _POSIX_ values (e.g. NGROUPS_MAX is defined in terms of _POSIX_NGROUPS_MAX), and increase the size of the _POSIX_ limits as suggested in the rev. note. Remove the rev note." The reviewers note had been in there since D1, and said "D1, XSH, ERN 19 proposes to increase {_POSIX_NGROUPS_MAX}, {_POSIX_OPEN_MAX}, and {_POSIX_CHILD_MAX} to their FIPS values (8, 20, 25) as with the limits equivalents without the leading _POSIX)." We did the change for NGROUPS_MAX and OPEN_MAX but missed CHILD_MAX. Action: Change 6 to 25 [Ed recommendation: Accept This should go into TC1 ] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 mccann@zk3.dec.com BUGs in XBD Issue 6 (rdvk# 8) [JMXBD6-4] Tue, 5 Feb 2002 15:38:02 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9873 Section: Problem: Defect code : 2. Omission The IETF IPv6 API specification defines a flag NI_NUMERICSCOPE for use with getnameinfo. This flag is missing from the Austin spec. See related XSH bug report [JMXSH6-9]. Action: Insert the following text between lines 9873 and 9874: NI_NUMERICSCOPE For IPv6 addresses, the numeric form of the scope identifier is returned instead of its name. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 24 mccann@zk3.dec.com BUGs in XBD Issue 6 (rdvk# 5) [JMXBD6-1] Tue, 5 Feb 2002 15:38:02 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 277 Line: 9908 Section: Problem: Defect code : 1. Error In the function prototype for the getnameinfo() function, the datatype of the last argument is "unsigned", it should be "int". This is for alignment with the IETF IPv6 API specification. See related XSH bug report [JMXSH6-5]. Action: Change "unsigned" to "int". (TC1 candidate, rationale The Open Group has put an interpretation on the record against XNS5.2 recommending a change to int. This matches most existing practise and the RFCs) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 25 mccann@zk3.dec.com BUGs in XBD Issue 6 (rdvk# 6) [JMXBD6-2] Tue, 5 Feb 2002 15:38:02 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Also there is an additional action on adjg (see minutes) _____________________________________________________________________________ Page: 279 Line: 9979 Section: Problem: Defect code : 2. Omission The declaration for in6addr_any is missing a const qualifier. This is for alignment with the IETF IPv6 API specification. Action: Insert "const" in front of "struct in6_addr in6addr_any". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 mccann@zk3.dec.com BUGs in XBD Issue 6 (rdvk# 7) [JMXBD6-3] Tue, 5 Feb 2002 15:38:02 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 280 Line: 9985 Section: Problem: Defect code : 2. Omission The declaration for in6addr_loopback is missing a const qualifier. This is for alignment with the IETF IPv6 API specification. Action: Insert "const" in front of "struct in6_addr in6addr_loopback". _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 drepper@redhat.com Defect in XBD (rdvk# 14) {ud-15} Wed, 20 Mar 2002 08:36:05 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 290 Line: , Section: Problem: Defect code : 1. Error The pthread_mutexattr_getpshared(), pthread_mutexattr_setpshared(), functions pthread_rwlockattr_getpshared() and pthread_rwlockattr_setpshared() are unconditionally required if _POSIX_THREADS is defined. This contradicats XSH where the functions are correctly marked with TSH. Action: Shade lines 10310-10311, 10317, 10333-10334 and 10336 and mark them with TSH. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 drepper@redhat.com Defect in XBD (rdvk# 24) {ud-17} Wed, 20 Mar 2002 23:11:37 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 287 Line: 10196-10198 Section: Problem: Defect code : 1. Error The shading of the PTHREAD_PRIO_* constants is somewhat simplified as TPP|TPI. In fact, only PTHREAD_PRIO_NONE is required for TPP and TPI. PTHREAD_PRIO_INHERIT does only have to be available for TPI and PTHREAD_PRIO_PROTECT only has to be available for TPP. Action: - Mark line 10196 with TPI - Mark line 10197 with TPP|TPI - Mark line 10198 with TPP _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 drepper@redhat.com Defect in XBD (rdvk# 23) {ud-18} Thu, 21 Mar 2002 05:26:07 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 288 Line: 10232 Section: Problem: Defect code : 1. Error The TPS marker on line 10232 is not necessary since the previous prototype also belongs to this group. Action: Remove TPS from line 10232. [Ed recommendation: Accept this is not serious enough to warrant a corrigenda, it may also be here to make the postscript shading work in the hardcopy] _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 drepper@redhat.com Defect in XBD (rdvk# 25) {ud-16} Wed, 20 Mar 2002 22:46:27 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 288 Line: 10238,10250 Section: Problem: Defect code : 1. Error In the man page the pthread_attr_getstacksize() and pthread_attr_setstacksize() are marked with TSA (thread stack address). They belong into the thread stack size (TSS) group, though. Action: Mark lines 10238 and 10250 with TSS. [Ed recommendation: Accept (there is also a DR against XSH that should be accepted)] _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 drepper@redhat.com Defect in XBD (rdvk# 15) {ud-14} Wed, 20 Mar 2002 08:23:29 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 290 Line: 10324-10327 Section: Problem: Defect code : 1. Error The functions pthread_rwlock_timedrdlock() and pthread_rwlock_timedwrlock() are unconditionally required if _POSIX_THREADS is defined. The timeout variants of all other synchronization functions are required only if _POSIX_TIMEOUTS is defined. I think these two functions should also be governed by the same option. Action: Shade lines 10324-10327 and mark them TMO. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 32 drepper@redhat.com Defect in XBD (rdvk# 22) {ud-19} Thu, 21 Mar 2002 05:31:30 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 290 Line: 10344 Section: Problem: Defect code : 1. Error The TPS marker on line 10344 is not necessary since the previous prototype also belongs to this group. Action: Remove TPS from line 10344. [Ed recommendation: Accept this is not serious enough to warrant a corrigenda, it may also be here to make the postscript shading work in the hard copy] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 drepper@redhat.com Defect in XBD (rdvk# 21) {ud-20} Thu, 21 Mar 2002 05:38:37 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 323 Line: 11560 Section: Problem: Defect code : 1. Error The TSF marker for putc_unlocked and putchar_unlocked is on the previous side on a line of its own. While not strictly wrong it certainly is irritating. Action: If possible move the TSF marker to the line of the first prototype for the TSF group. [Ed recommendation: Accept] _____________________________________________________________________________ COMMENT Enhancement Request Number 34 schilling@fokus.gmd.de BUG in XBD6 (rdvk# 41) Tue, 30 Apr 2002 22:56:41 +0200 (CEST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: For TC1: Add rationale: The units for the st_blocks member of the stat structure is not defined within the standard. In some implementations it is 512 bytes. It may differ on a filesystem basis.There is no correlation between values of the st_blocks and st_blksize and the f_bsize (from ) structure members. Traditionally some implementations defined the multiplier for st_blocks in as the symbol DEV_BSIZE Proposed Interpretation of 1003.1-2001 "The standard does not speak to the issue of the units of the st_blocks member of the stat structure, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." _____________________________________________________________________________ Page: 355 Line: 12638 Section: Problem: Also line 12754 The standard mentions the struct stat member st_blocks but does not mention the blocksize (e.g. multiplicator) to be used with the st_blocks field. Without knowing the blocksize, the field 'st_blocks' does not make sense. Action: Add a definition for the blocksize after lines 12754/12755. As all known UNIX implementations (except HP-UX) use 512 bytes as multiplicator for the blocksize used with st_blocks, it would make sense to standardize on 512 byte blocks for this field. _____________________________________________________________________________ COMMENT Enhancement Request Number 35 bjh21@netbsd.org Defect in XBD (rdvk# 37) {bjh21:1} Fri, 26 Apr 2002 11:18:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Withdrawn by originator _____________________________________________________________________________ Page: 369 Line: 13048 Section: Problem: Defect code : 1. Error has an XSI-shaded SYNOPSIS, but it and the struct iovec it defines are referred to from non-XSI-shaded text under . This seems inconsistent to me. Action: Remove XSI shading from the SYNOPSIS of Add XSI shading to from "The ssize_t and size_t types" to the end of the section. _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 drepper@redhat.com Defect in XBD (rdvk# 16) {ud-12} Wed, 20 Mar 2002 06:06:05 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: note the actual page number is 340 XBD _____________________________________________________________________________ Page: 385 Line: 12114 Section: Problem: Defect code : 1. Error The functions mlock() and munlock() are marked with ML (_POSIX_MEMLOCK option) in the man page. They belong to the _POSIX_MEMLOCK_RANGE option, though. Action: - Change marker for line 12114 to MLR - Add ML as marker for line 12115 - Change merger for line 12119 to MLR - Add ML as marker for line 12120 _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 mgh@unican.es Defect in XBD (rdvk# 35) Tue, 23 Apr 2002 11:31:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 398 Line: 13998-14266 Section: unistd.h Problem: The _POSIX_IPV6 symbol appears in the conformance section 2.1.3, but is not included in Action: Add the _POSIX_IPV6 symbol and description to the unistd.h header [Ed recommendation: Accept as marked Add to XBD p 399 after line 14061 _POSIX_IPV6 The implementation supports the IPv6 option. If this symbol has a value other than -1 or 0, it shall have the value 200112L. ] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 SHwareSyst@aol.com Defect in XBD unistd.h (rdvk# 38) {020425-01} Fri, 26 Apr 2002 06:37:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is not a bug in the standard. Accepted in principle as a good idea, but not felt to be a candidate for TC1 or an interpretation. It was agreed to recommend that consideration for this approach be given in the next revision. _____________________________________________________________________________ Page: 398 Line: 14001 Section: unistd.h Problem: Defect code : 2. Omission The Specification makes reference in unistd.h to POSIX2_C_BIND option group designator, yet nowhere summarizes or specifies which headers, interfaces and utilities are part of this option group, or even provides a margin notation allowing to designate those features. While this group may no longer be considered optional, as the header says the ident shall be defined, for completeness sake such a summary and notation should be provided. The same lack of completeness applies to the _POSIX2_CHAR_TERM and the UPE Group identifiers. Per request below, addressing this would provide a succinct but complete functionally ordered index of what comprises each of the levels of Conformance. Right now everything is pretty much scattered over the four volumes. Also, though this is more a nit, there's no succinct splitout of which headers and interfaces are mandated as part of the c99 and fort77 specs, which ones define the hosting API for those compilers, and which are there just to support other utilities or application classes. Action: Ideally, having a separate page in XBD with a table listing each Option Group Identifier and the headers, interfaces, utilities, and sub-groups affected would be welcome... e.g.: POSIX Mandatory Headers: xxxx.h.html, ... Interfaces: xxx(), ... Utilities: ueil1, util2, ... POSIX Options, not part of XOPEN base or Option Groups Option_Ident1 Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... Option_Ident2 Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... XSI Base Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... Option Group1 promoted to mandatory Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... Option Group2 promoted to mandatory Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... XSI Option Group1 POSIX Option1 Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... POSIX Options2 Headers: xxxx.h.html, ... Interfaces: xxx().html, ... Utilities: util1.html, ... etc. If a referenced page is affected by more than one identifier, that reference should be duplicated, perhaps excepting unistd.h as it's part of all groups. The Margin Codes summary pop-up could also be extended to link back to the appropriate section of this summary page. _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 drepper@redhat.com Defect in XBD (rdvk# 19) {ud-8} Wed, 20 Mar 2002 01:42:46 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See Ed recommendation _____________________________________________________________________________ Page: 400 Line: 14085 Section: Problem: Defect code : 1. Error The table for the options and options groups contains: _POSIX_NO_TRUNC Pathname components longer than {NAME_MAX} generate an error. This symbol shall always be set to a value other than -1. Either "other than -1" should actually be "greater than 0" or this is a horrible requirement. Requiring this option never to be -1 only means that a platform which does not support _POSIX_NO_TRUNC cannot signal this directly but instead must require the application to use pathconf(). I suspect therefore it's a typo and "greater than 0" is meant and this option is required to always be supported. Action: Replace in line 14085 other than -1 with greater than 0 [Ed recommendation: Reject The change request which required this was XBDd5 ERN 374 The rationale if i recall correctly, is that FIPS 151-2 mandated this option, hence it can never be set to -1 (i.e. cannot be set to not supported), however a conforming system might have a filesystem which has non conforming semantics (and truncates filenames)-- thus at runtime you could get a result that said it was not supported for example on my laptop I might get pathconf("/home/ajosey/", _PC_NO_TRUNC) > 0 pathconf ("/dosc/My Docu~1", _PC_NO_TRUNC) returns -1 This issue is also addressed in XBD section 2.1.3.1 lines 655-668 ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 drepper@redhat.com Defect in XBD (rdvk# 18) {ud-10} Wed, 20 Mar 2002 04:31:43 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No explicit change required other than the application usage noted below It was felt that the standard is correct as is. XSI systems always support _XOPEN_SHM In XSH5 this was defined to be a symbol with value other than -1 So it could have taken the value 0 so existing XSH6 wording allows XSH5 definitions In XSH6 the semantics are now defined for 0, which means you need to query at runtime whether support is provided. Add to APP USAGE New applications should not use _XOPEN_SHM or _XOPEN_ENH_I18N _____________________________________________________________________________ Page: 403 Line: 14261 Section: Problem: Defect code : 1. Error Similar to the _POSIX_NO_TRUNC and _XOPEN_ENH_I18N reports. For _XOPEN_SHM the requirement is also to be != -1 all the time. All the requirement adds is that systems without support for this option must define it to zero and have getconf() return a negative answer. Action: If the functionality is indeed required for all implementations replace other than -1 with greater than 0 Otherwise remove the whole sentence. [Ed recommendation: None. I think this is a different case to _POSIX_NO_TRUNC. On XSI systems the functionality associated with this symbol is always mandatory, its presence here is merely for backwards compatibility, since there was an option in XPG4 denoted by _XOPEN_ENH_I18N (and also _XOPEN_SHM). Unfortunately when the option rules in XBD unistd.h lines 14021-14039 were changed to have the 0 case(a .1a change), this and also _XOPEN_SHM should have been changed from: "a value of -1" to "greater than 0" ] _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 drepper@redhat.com Defect in XBD (rdvk# 17) {ud-11} Wed, 20 Mar 2002 05:33:54 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 410 Line: 14558 Section: Problem: Defect code : 1. Error Unlike in XSH the fsync() function isn't marked with FSC. Action: Shade line 14558 and mark with FSC. [Ed recommendation: Accept This should go into TC1] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 42 ajosey@opengroup.org Defect in XBD termios.h (rdvk# 1) {tc1-3} Mon, 14 Jan 2002 16:37:59 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 427 Line: 13463 Section: termios.h Problem: Defect code : 1. Error The APPLICATION USAGE is inconsistent with the symbols reserved in XSH6 section 2.2.2 page 18. Minimally at least ECHOK should be ECHOKE. A better fix might be to consider revising the text, so that there is just a pointer to the XSH section 2.2.2 which is normative text and no duplication of the information in two places. Action: Minimally replace ECHOK with ECHOKE. [Ed recommendation: None] _____________________________________________________________________________ COMMENT Enhancement Request Number 43 schilling@fokus.gmd.de BUG in XCU (rdvk# 40) Tue, 30 Apr 2002 23:40:04 +0200 (CEST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Out of scope for TC1 or interpretation. Recommend that this follow the route outlined for new submissions as per Austin/106. _____________________________________________________________________________ Page: 716 Line: 27689 Section: pax Problem: (Ed:bug filed incorrectly against XBD, should be XCU, also page and linenos corrected to finaltext) The standard defines: 27700 The typeflag field specifies the type of file archived. If a particular implementation does not 27701 recognize the type, or the user does not have appropriate privilege to create that type, the file 27702 shall be extracted as if it were a regular file if the file type is defined to have a meaning for the 27703 size field that could cause data logical records to be written on the medium (see the previous 27704 description for size). If conversion to a regular file occurs, the pax utility shall produce an error While this definition is perfect for all file types defined in the PAX standard, it prevents to use the PAX format from being used for incremental backups purposes. To allow incremental backup utilities to use the PAX archive format, there needs to be a 'meta data only' file type that only holds the file's meta data but does not include file content in the archive. Such a 'meta' file type would need to specify 0 for the file size used in the TAR header as no data is included in the archive. Any PAX implementation that knowns about the the 'meta' file type would not create a zero sized file on extraction but just change the meta data of the file on disk. As the current standard does not include a 'meta data' file type, a conforming PAX implementation would not nderstand a enhanced archive containing meta data only files in the archive and for this reason such a PAX implementation would _create_ a zero sized file instead of extracting the file meta data only. To avoid the problems mentioned above, we need to add a 'meta data' file type and require a conforming PAX implementation not to try to create a zero sized file in case a 'meta data' file is found in a PAX archive. Action: Add these definitions after line 27730: '8' (or better 'm' ???) Reserved for meta data file information. The size field may either be 0 or equal to the size of the file whichs meta data is recorded. A conforming PAX implementation that does not implement the 'meta data' file type shall ignore the size field (treat as if it were zero) and shell never try to create a file if in extract mode. This file type is primarily intended to archive file meta data and does not include file content. If the PAX implementation does not implement the meta data file type, it shall completely ignore this file type. P.S. If you don't consider this as a bug, please take it as request for enhancement.