Minutes of the 21 March 2013 Teleconference Austin-600 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 22 March 2013 Attendees Don Cragun, PASC OR Andrew Josey, The Open Group Eric Blake, Red Hat Nick Stoughton, USENIX, ISO/IEC OR Geoff Clare, The Open Group Jim Pugsley, Oracle Mark Brown, IBM, TOG OR Joerg Schilling, Fraunhofer Society Richard Hansen, BBN * General News Andrew reported that the TC has now been published by IEEE and The Open Group. It can be obtained from The Open Group as Document U130 https://www2.opengroup.org/ogsys/catalog/U130 and from IEEE as http://www.techstreet.com/cgi-bin/pdf/free/1078422/1003.1-2008_Cor1-2013.pdf The merged document is in the final stages of preparation, including both PDF and html. We are awaiting completion of the front matter and the ISBN numbers from IEEE and aim to publish ASAP. The ISO version of the TC was sent to the ANSI secretariat on Friday March 15. The text is identical just the cover and running header differs. * Old Business +Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN http://austingroupbugs.net/view.php?id=561 Eric has an action to update the proposal. +Bug 0000573: Please add '+' to the portable filename character set OPEN http://austingroupbugs.net/view.php?id=573 Joerg has an action to prepare a proposed change. +Bug 0000592: consistent use of struct timespec OPEN http://austingroupbugs.net/view.php?id=592 This item needs further investigation of existing implementations. Mark reported that AIX does not have a problem with this. Jim notes he is still looking at this. +Bug 0000598: OH shading and new interfaces OPEN http://austingroupbugs.net/view.php?id=598 Eric has an action to propose a new solution with self-contained headers. Bug 0000576: No format specifiers for several types OPEN http://austingroupbugs.net/view.php?id=576 Bug 0000599: Reserved "no thread" value for pthread_t A/M Issue 8 Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 It was agreed that we need Joerg's input on this item and have left it open for now. Andrew took an action on the 12 September call to notify Joerg (completed after the meeting). * Current Business Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 This item was again left open pending further feedback. Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN http://austingroupbugs.net/view.php?id=657 Eric has an action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. Bug 0000656: Clearly allow or forbid thread-local storage for "static" buffers OPEN http://austingroupbugs.net/view.php?id=656 Don has an action to propose wording changes to all of the same places that bug 75 modified. Bug 0000654: unclear behavior of in-line variable assignments preceding functions, special built-ins OPEN http://austingroupbugs.net/view.php?id=654 Richard has volunteered to take an action to draft some words. Bug 0000658: Undefined/unspecified behavior clauses in description of open have race conditions OPEN http://austingroupbugs.net/view.php?id=658 It was noted that there is some overlap with changes in TC1. Eric took an action to update the proposal to resolve the overlaps appropriately. We will pick up with this one next time. A reminder for next week is to look at bug 573 (if Joerg has completed his action) Bug 0000666: RE_DUP_MAX is listed as both runtime invariant and runtime increasable Accept as Marked http://austingroupbugs.net/view.php?id=666 Geoff had completed his action from last time in bugnote 1493. This item is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: None. Notes to the Editor (not part of this interpretation): At page 270 line 8853-8856 delete: {RE_DUP_MAX} Maximum number of repeated occurrences of a BRE or ERE interval expression; see Section 9.3.6 (on page 186) and Section 9.4.6 (on page 189). Minimum Acceptable Value: {_POSIX2_RE_DUP_MAX} At page 273 line 9002-9003 change: Maximum number of repeated occurrences of a regular expression permitted when using the interval notation \{m,n\}; see Chapter 9 (on page 181). to (copied from line 8854): Maximum number of repeated occurrences of a BRE or ERE interval expression; see Section 9.3.6 (on page 186) and Section 9.4.6 (on page 189). At page 273 line 9004 change: {_POSIX2_RE_DUP_MAX} to: {_POSIX_RE_DUP_MAX} At page 275 line 9076-9077 change: The number of repeated occurrences of a BRE permitted by the regexec() and regcomp() functions when using the interval notation {\(m,n\}; see Section 9.3.6 (on page 186). to (copied from line 8854): Maximum number of repeated occurrences of a BRE or ERE interval expression; see Section 9.3.6 (on page 186) and Section 9.4.6 (on page 189). At page 277 line 9174-9175 change: Maximum number of repeated occurrences of a regular expression permitted when using the interval notation \{m,n\}; see Chapter 9 (on page 181). to (copied from line 8854): Maximum number of repeated occurrences of a BRE or ERE interval expression; see Section 9.3.6 (on page 186) and Section 9.4.6 (on page 189). Cross-volume changes to XCU... At page 2285 line 71853 section 1.2 change: {_POSIX2_RE_DUP_MAX} to: {_POSIX_RE_DUP_MAX} At page 2285 line 71853-71856 section 1.2 change: The maximum number of repeated occurrences of a BRE permitted when using the interval notation \{m,n\}; see XBD Section 9.3.6 (on page 186). to: Maximum number of repeated occurrences of a BRE or ERE interval expression; see XBD Section 9.3.6 (on page 186) and XBD Section 9.4.6 (on page 189). At page 2287 line 71911-71916 section 1.2 change: The maximum number of repeated occurrences of a BRE permitted when using the interval notation \{m,n\}; see XBD Section 9.3.6 (on page 186). to: Maximum number of repeated occurrences of a BRE or ERE interval expression; see XBD Section 9.3.6 (on page 186) and XBD Section 9.4.6 (on page 189). At page 2287 line 71911 section 1.2 change: {_POSIX2_RE_DUP_MAX} to: {_POSIX_RE_DUP_MAX} Bug 0000663: Specification of str[n]casecmp is ambiguous Accepted as Marked http://austingroupbugs.net/view.php?id=663 This item is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard clearly states that the POSIX locale is a synonym for the C locale with regards to LC_CTYPE, and defers to the C standard for its definitions of character categories. The C standard is clear that only 26 uppercase and 26 lowercase letters exist in the C locale, all of which have single-byte encodings. Rationale: While the POSIX locale may include multibyte characters, it must still honor the C locale rules. Since the C locale has only 26 characters that can be altered by tolower(), all of which are single bytes, it does not matter whether strcasecmp() and strncasecmp() use byte or character normalization, and the length limit of strncasecmp() is specified in bytes. We are also seeking proposals for the standardization of a "POSIX.UTF-8" locale for Issue 8. Notes to the Editor (not part of this interpretation): Make the following changes: On page 136 line 3849 [7.2 POSIX locale], move the following sentences: The tables in Section 7.3 describe the characteristics and behavior of the POSIX locale for data consisting entirely of characters from the portable character set and the control character set. For other characters, the behavior is unspecified. to page 151 line 4531 [7.3.2.6 LC_COLLATE Category in the POSIX Locale], with a wording change: The definition below describes the behavior of the POSIX locale for data consisting entirely of characters from the portable character set and the control character set. For other characters, the behavior is unspecified. On page 139 line 3996 [7.3.1 LC_CTYPE upper], change: In the POSIX locale, the 26 uppercase letters shall be included: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z to: In the POSIX locale, only: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z shall be included. On page 139 line 4003 [7.3.1 LC_CTYPE lower], change: In the POSIX locale, the 26 lowercase letters shall be included: a b c d e f g h i j k l m n o p q r s t u v w x y z to: In the POSIX locale, only: a b c d e f g h i j k l m n o p q r s t u v w x y z shall be included. On page 139 line 4009 [7.3.1 LC_CTYPE alpha], change: In the POSIX locale, all characters in the classes upper and lower shall be included. to: In the POSIX locale, only characters in the classes upper and lower shall be included. On page 141 line 4091 [7.3.1 LC_CTYPE toupper], change: In the POSIX locale, at a minimum, the 26 lowercase characters: to: In the POSIX locale, the 26 lowercase characters: On page 142 line 4105 [7.3.1 LC_CTYPE tolower], change: In the POSIX locale, at a minimum, the 26 uppercase characters: to: In the POSIX locale, the 26 uppercase characters: On page 143 line 4145 [7.3.1.1 LC_CTYPE Category in the POSIX Locale], change: # The following is the POSIX locale LC_CTYPE. # "alpha" is by default "upper" and "lower" # "alnum" is by definition "alpha" and "digit" # "print" is by default "alnum", "punct", and the # "graph" is by default "alnum" and "punct" to: # The following is the minimum POSIX locale LC_CTYPE; implementations may # add additional characters to the "cntrl" and "punct" classifications. # "alpha" is by definition "upper" and "lower" # "alnum" is by definition "alpha" and "digit" # "print" is by definition "alnum", "punct", and the # "graph" is by definition "alnum" and "punct" At page 151 line 4534 [7.3.2.6 LC_COLLATE Category in the POSIX Locale], change: # This is the POSIX locale definition for the LC_COLLATE category. # The order is the same as in the ASCII codeset. to: # This is the minimum input for the POSIX locale definition for the # LC_COLLATE category. Characters in this list are in the same order # as in the ASCII codeset. Next Steps ---------- The next call is on March 28 2013 (a Thursday) Calls are anchored on US time. This call will be for the regular 90 minutes. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs