Document Number: AUSTIN/107
Title: XBDft Aardvark Change Request Report (draft)
Revision Date: 2002-05-10
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 Reject
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 <sys/mman.h> 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 <unistd.h>, 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 <unistd.h>, 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 <unistd.h>, 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 define the table contents for lines 4886-4902 (there
is an action on Ulrich)
________________________________________________________________________________
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_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The consensus is that
If TZ is changed by one thread while another thread is using one of
the time functions the behavior is undefined.
hence we should address this as follows:
(candidate for TC1)
Add text at the end of the pararaph 5569-5572 marked THR
If an environment variable is modified by one thread while it is being
used, implicitly by the implementation or explicitly by the application,
in another thread the behavior is undefined
_____________________________________________________________________________
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
<http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap09.html#tag_09>
does not reflect the resolutions of the June 1995 POSIX RE experts
meeting as reported by David Korn in
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group
-l&id=3713>
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 <gsf@research.att.com>
Andrew Hume <andrew@research.att.com>
David Korn <dgk@research.att.com>
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
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=3934>
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: <netdb.h>
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_____ Accept as marked below_____ Duplicate_____ Reject_X___
Rationale for rejected or partial changes:
See XSH rdvk JMXSH6-5
_____________________________________________________________________________
Page: 277 Line: 9908 Section: <netdb.h>
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".
_____________________________________________________________________________
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: <netinet/in.h>
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: <netinet/in.h>
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 <pthread.h> (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: <pthread.h>
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 <pthread.h> (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: <pthread.h>
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 <pthread.h> (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: <pthread.h>
Problem:
Defect code : 1. Error
<pedantic>
The TPS marker on line 10232 is not necessary since the previous
prototype also belongs to this group.
</pedantic>
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 <pthread.h> (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: <pthread.h>
Problem:
Defect code : 1. Error
In the <pthread.h> 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 <pthread.h> (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: <pthread.h>
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 <pthread.h> (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: <pthread.h>
Problem:
Defect code : 1. Error
<pedantic>
The TPS marker on line 10344 is not necessary since the previous
prototype also belongs to this group.
</pedantic>
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 <stdio.h> (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: <stdio.h>
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 <sys/statvfs.h>)
structure members.
Traditionally some implementations defined the
multiplier for st_blocks in <sys/param.h> 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: <sys/stat.h>
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 <sys/uio.h> (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: <sys/uio.h>
Problem:
Defect code : 1. Error
<sys/uio.h> has an XSI-shaded SYNOPSIS, but it and the struct iovec it
defines are referred to from non-XSI-shaded text under <sys/socket.h>.
This seems inconsistent to me.
Action:
Remove XSI shading from the SYNOPSIS of <sys/uio.h>
Add XSI shading to <sys/uio.h> 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 <sys/mman.h> (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: <sys/mman.h>
Problem:
Defect code : 1. Error
The functions mlock() and munlock() are marked with ML (_POSIX_MEMLOCK
option) in the <sys/mman.h> 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 <unistd.h>
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.
The consensus was that whilst it might be a useful
commentary to the standard, it is a major work item
that would not be addressed in the short term. There were
some concerns about maintenance and viability of some approaches,
it was felt that the Guide books provide a vehicle for some
of this.
_____________________________________________________________________________
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 <unistd.h> (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: <unistd.h>
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 <unistd.h> (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: <unistd.h>
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 <unistd.h> (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: <unistd.h>
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.