Minutes of the 18th October 2018 Teleconference Austin-890 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 19th October 2018 Attendees: Joerg Schilling, FOKUS Fraunhofer Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Geoff Clare, The Open Group Don Cragun, IEEE PASC OR Martin Rehak, Oracle, The Open Group OR Mark Ziegast, SHware Systems Eric Blake, Red Hat Apologies: David Clissold, IBM * General news Please note that US daylight saving time ends November 4th so there will be a week where the offset between Europe and the USA differs. As a reminder calls are anchored on US time, so that week the call will be one hour earlier in Europe. * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 9 March 2018 and earlier) Bug 1077: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1077 Andrew has completed the action to ping his Apple contact and is awaiting a reply. Bug 1122: POSIX should include gettext() and friends OPEN http://austingroupbugs.net/view.php?id=1122 Left open as an action is still in progress to flesh out a complete proposal. * Current Business Bug 1134: Add getentropy interface OPEN http://austingroupbugs.net/view.php?id=1134 Action: Andrew to add boilerplate response regarding a proposal for new interface, and also to ask The Open Group OR if they would sponsor this addition. Both Actions now Completed. (update 19 Oct 2018) There has been no reaction from the Base Working Group and the period for comments has ended now. Bug 1138: Add strsignal(), sig2str() and str2sig() to the standard. OPEN http://austingroupbugs.net/view.php?id=1138 Martin has completed his action. Andrew took an action to chase the Base Working group members for sponsorship of the two interfaces. Bug 1139: require RE \] to match ] when outside bracket expressions Accepted as Marked http://austingroupbugs.net/view.php?id=1139 Geoff completed his action item to come up with specific editing instructions. This item is tagged for Issue 8. Proposed changes ... On 2016 edition page 183 line 6043 section 9.3.1 change: A BRE ordinary character, a special character preceded by a , or a shall match a single character. to: When not inside a bracket expression, the following shall match a single character: a BRE ordinary character a BRE special character or ']' preceded by an unescaped a . On 2016 edition page 183 line 6049 section 9.3.2 change: The interpretation of an ordinary character preceded by an unescaped ('\\') is undefined, except for: The characters ')', '(', '{', and '}' The digits 1 to 9 inclusive (see [xref to 9.3.6]) A character inside a bracket expression to: When not inside a bracket expression, the interpretation of an ordinary character preceded by an unescaped is undefined, except for: The characters ')', '(', '{', and '}' The digits 1 to 9 inclusive (see [xref to 9.3.6]) The ']' character; "\]" shall match a ']' character On 2016 edition page 184 line 6056 section 9.3.3 change: preceded by a to: preceded by an unescaped On 2016 edition page 184 line 6073 section 9.3.4 change: A ('.'), when used outside a bracket expression, is ... to: When not inside a bracket expression, a ('.') is ... On 2016 edition page 188 line 6261 section 9.4.1 change: An ERE ordinary character, a special character preceded by a or a shall match a single character. to: When not inside a bracket expression, the following shall match a single character: an ERE ordinary character an ERE special character, ']', or '}' preceded by an unescaped a . On 2016 edition page 188 line 6268 section 9.4.2 change: The interpretation of an ordinary character preceded by an unescaped ('\\') is undefined, except in the context of a bracket expression (see [xref to 9.4.5]). to: When not inside a bracket expression, the interpretation of an ordinary character preceded by an unescaped is undefined, except for the ']' and '}' characters; "\]" and "\}" shall match the ']' and '}' characters, respectively. On 2016 edition page 189 line 6272 section 9.4.3 change: preceded by a to: preceded by an unescaped On 2016 edition page 189 line 6277 section 9.4.3 change: Outside a bracket expression, a immediately followed by a produces undefined results. to: When not inside a bracket expression, an unescaped immediately followed by a produces undefined results. On 2016 edition page 189 line 6281 section 9.4.3 change: both outside a bracket expression to: both not inside a bracket expression On 2016 edition page 189 line 6298 section 9.4.4 change: A ('.'), when used outside a bracket expression, is ... to: When not inside a bracket expression, a ('.') is ... On 2016 edition page 191 line 6364 section 9.4.9 change: when used anywhere outside a bracket expression to: when used anywhere except inside a bracket expression On 2016 edition page 191 line 6365 section 9.4.9 change: A ('^') outside a bracket expression shall ... to: When not inside a bracket expression, a ('^') shall ... On 2016 edition page 191 line 6371 section 9.4.9 change: A ('$') outside a bracket expression shall ... to: When not inside a bracket expression, a ('$') shall ... On 2016 edition page 192 line 6406 section 9.5.1 change: In a BRE, one of the character sequences: \^ \. \* \[ \$ \\ In an ERE, one of the character sequences: \^ \. \[ \$ \( \) \| \* \+ \? \{ \\ to: In a BRE, one of the character sequences: \^ \. \* \[ \] \$ \\ In an ERE, one of the character sequences: \^ \. \[ \] \$ \( \) \| \* \+ \? \{ \} \\ On 2016 edition page 193 line 6416,6417,6418,6425 section 9.5.1 change: Anywhere outside bracket expressions to: Anywhere except inside bracket expressions Bug 1140: must the encoded output end with a zero-length line? Accepted as Marked http://austingroupbugs.net/view.php?id=1139 This item is tagged for TC3-2008 An interpretation is required. Interpretation response: The standard states the historical uuencode output format, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Almost all uudecode implementations require a line just before the "end" line specifying a line of zero bytes to be converted. Some historic uuencode implementations output a while others output of a to encode this zero length final line. The changes below allow either historic behavior. Notes to the Editor (not part of this interpretation): Make the changes in Note: 0004150. Note 4150: On 2016 edition page 3362 line 113245 section uuencode, change: These octets shall be converted to characters by adding a value of 0x20 to each octet, so that each octet is in the range [0x20,0x5f], and then it shall be assumed to represent a printable character in the ISO/IEC 646:1991 standard encoded character set. It then shall be translated into the corresponding character codes for the codeset in use in the current locale. (For example, the octet 0x41, representing 'A', would be translated to 'A' in the current codeset, such as 0xc1 if it were EBCDIC.) to: These octets shall be converted to characters in the ISO/IEC 646:1991 standard encoded character set by adding a value of 0x20 to each octet, so that each octet is in the range [0x20,0x5f], and then optionally replacing any 0x20 octets with 0x60. If necessary, these characters shall then be translated into the corresponding character codes for the codeset in use in the current locale. For example, the octet 0x41, representing 'A', would be translated to 'A' in the current codeset, such as 0xc1 if it were EBCDIC; the octet 0x20, representing , would optionally be replaced with 0x60, representing '`', and then translated to either (0x40 if EBCDIC) or '`' (0x79 if EBCDIC), respectively. On 2016 edition page 3362 line 113258 section uuencode, change: These octets then shall be translated into the local character set. to: before any replacement of 0x20 with 0x60 and translation into the local character set. On 2016 edition page 3362 line 113259 section uuencode, change: Each encoded line contains a length character, equal to the number of characters to be decoded plus 0x20 translated to the local character set as described above, followed by the encoded characters. The maximum number of octets to be encoded on each line shall be 45. to: Each encoded line shall contain a length character, equal to the number of characters to be decoded plus 0x20 translated to the local character set as described above, followed by between 1 and 45, inclusive, encoded characters. The last encoded line, or the begin line if the input is empty, shall be followed by a line containing only a or '`' character before the terminating . On 2016 edition page 3364 line 113309 section uuencode, add a new paragraph to RATIONALE: Historically the encoding used only octets in the range [0x20,0x5f], and thus the encoded lines could contain trailing spaces, which were at risk of being stripped by whatever transport method was used to send the file. To avoid this problem some implementations use 0x60 instead of 0x20, resulting in '`' characters instead of spaces in the output, and implementations are encouraged to do this. Bug 1141: Add WCOREDUMP(stat) to sys/wait.h OPEN http://austingroupbugs.net/view.php?id=1141 We started discussing this item and will continue next time. Next Steps ---------- The next call is on October 25th 2018 (Thursday). Apologies in Advance: Eric Blake, 2018-10-25 Martin Rehak, 2018-10-25 Andrew Josey, 2018-11-01 Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756#