Minutes of the 28th April 2022 Teleconference Austin-1217 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 29th April 2022 Attendees: Mark Ziegast, SHware Systems Dev. Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Eric Blake, Red Hat, The Open Group OR Geoff Clare, The Open Group Apologies: Eric Ackermann, HPI, University of Potsdam * General news This was a call dedicated to general bugs. Eric took an action to send a mail to The Open Group to call for sponsorship of the gettext interface. * Outstanding actions Bug 1533: struct tm: add tm_gmtoff (and tm_zone) field(s) OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1533 This was discussed in the February 3, 2022 teleconference. Leave it open until we get a more complete suggestion for the Desired Action. * Current Business Bug 1550: clarifications/ambiguities in the description of context addresses and their delimiters for sed Accepted as Marked https://austingroupbugs.net/view.php?id=1550 This item is tagged for Issue 8 Updated proposal following further discussion on the mailing list ... These changes are to fix this bug and also bugs 0001551 and 0001556. On page 3134 line 106070 section sed, change: or a context address (which consists of an RE, as described in [xref to Regular Expressions in sed], preceded and followed by a delimiter, usually a ). to: or a context address. A context address has either the form "/RE/" or "\cREc", where RE is a regular expression as described in [xref to Regular Expressions in sed], and c is any character other than or . In a sed context address, the BRE and ERE syntax shall be extended to support escaping occurrences of the or c delimiter within the RE by means of an escape sequence (see [xref to XBD 9.1]). For the "\cREc" form, if the character designated by c is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escape sequence c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence c is treated as the literal character or the special character. In either case, the escape sequence c shall not terminate the RE. For example, in the context address "/abc\/def/", the second stands for itself, so that the RE is "abc/def", and in "\xabc\xdefx", the second 'x' stands for itself, so that the RE is "abcxdef". On page 3134 line 106085 section sed, change: Both BREs and EREs shall also support the following additions to: In sed, the BRE and ERE syntax shall be extended as follows On page 3134 line 106087 section sed, replace the first bullet item (beginning "In a context address") with: The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression, and shall have its normal meaning in the bracket expression. For example, the context address "\%[%]%" is equivalent to "/[%]/", and the command "s-[0-9]--g" is equivalent to "s/[0-9]//g". On page 3137 line 106204 section sed (s command), change: Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a . to: Within the RE (as a sed extension to the BRE and ERE syntax) and the replacement, the delimiter shall not terminate the RE or replacement if it is the second character of an escape sequence (see [xref to XBD 9.1]). If the delimiter character is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escaped delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escaped delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not ('&'), the escaped delimiter shall be treated as that literal character in the replacement; if it is , it is unspecified whether the escaped delimiter is treated as the literal character or the special character (see below). On page 3137 line 106221 section sed (s command), change: A substitution shall be considered to have been performed even if the replacement string is identical to the string that it replaces. Any used to alter the default meaning of a subsequent character shall be discarded from the RE or the replacement before evaluating the RE or using the replacement. to: Any used to alter the default meaning of a subsequent character shall be discarded from the resulting replacement string. A substitution shall be considered to have been performed even if the resulting replacement string is identical to the string that it replaces. On page 3138 line 106253 section sed (y command), change: ... the delimiter itself can be used as a literal character if it is preceded by a . If a character is immediately followed by a character in string1 or string2, the two characters shall be counted as a single literal character. to: ... the delimiter itself can be used as a literal character if it is preceded by an unescaped . If a character is escaped by an immediately preceding unescaped character in string1 or string2, the two characters shall be treated as a single literal character. On page 3138 line 106278 section sed, add a new paragraph to APPLICATION USAGE: Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a removes its special meaning. For example, for the context address "/\.[0-9]/" to be written with '.' as delimiter, the form "\.[.][0-9]." needs to be used; "\.\.[0-9]." cannot be used portably for this purpose, as it is unspecified whether this would be equivalent to "/\.[0-9]/" or "/.[0-9]/". Portable applications cannot use a special RE character as a delimiter if that character needs to have its special meaning in the RE, as escaping it may remove its special meaning. On page 3140 line 106354 section sed, add two new paragraphs to RATIONALE: The characters and cannot be used as RE delimiter characters, as they can never be recognized as the ending delimiter: does not work, because if it appears unescaped later in the RE, it either escapes the following character, which can then never be the ending delimiter, or it is part of a bracket expression, inside which the ending delimiter for the RE cannot be located. does not work, because if not escaped, it terminates the command, meaning it cannot be the ending delimiter. Some historical sed implementations did not support escaping '(', ')', '{', and '}' when used as a BRE delimiter, as the sequences "\(" and so on were still treated as special, usually resulting in an error. This standard requires that these sequences are treated as the literal character. This is for consistency with extensions. For example, some implementations treat "\s" in a BRE as matching white-space characters, as an extension. This cannot have its special meaning when 's' is used as a BRE delimiter in order to ensure portability of sed commands that have 's' as a delimiter and escape it. If "\s" were allowed to keep its special meaning, then the potential for further extensions would mean portable applications would not be able to escape any delimiter character other than . Bug 1551: sed: ambiguities in the how BREs/EREs are parsed/interpreted between delimiters (especially when these are special characters) Dup of 1550 https://austingroupbugs.net/view.php?id=1551 This is being closed as a duplicate of bug 1550 as bugnote:5816 includes changes to address it. Bug 1556: clarify meaning of \n used in a bracket expression in a sed context address or s-command Dup of 1550 https://austingroupbugs.net/view.php?id=1556 This is being closed as a duplicate of bug 1550 as bugnote:5816 includes changes to address it. Bug 1560: clarify wording of command substitution OPEN https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561, and 1564 open pending reviews/discussions. Bug 1562: printf utility: clarify what is (byte) string an what is character string Accepted as Marked https://austingroupbugs.net/view.php?id=1562 This item is tagged for TC3-2008 On page 898 line 30642 section fprintf(), and page 940 line 32183 section fscanf(), and page 1995 line 64733 section strftime(), change: The format is a character string, beginning and ending in its initial shift state, if any to: The application shall ensure that the format is a character string, beginning and ending in its initial shift state, if any Note to the editor: these pages are inconsistent about the use of italics on "format"; they should all use plain text, as in the C standard. On page 2017 line 65452 section strptime(), insert: The application shall ensure that the format is a character string, beginning and ending in its initial shift state, if any. before: The format is composed of zero or more directives. On page 3084 line 104239 section printf, change: A string describing the format to use ... to: A character string describing the format to use ... On page 3084 line 104241 section printf, change: The strings to be written ... to: The values to be written ... On page 3085 line 104273 section printf, insert: The application shall ensure that the format operand is a character string, beginning and ending in its initial shift state, if any. before: The format operand shall be used ... Bug 1576: The description of the pipe() function doesn't state which end of the pipe is placed in fildes[0] and fildes[1]. Accepted https://austingroupbugs.net/view.php?id=1576 This item is tagged for TC3-2008 Bug 1577: dup3 flags usage not entirely specified Accepted as Marked https://austingroupbugs.net/view.php?id=1577 Related to 1557 and 411 relationships added. This item is tagged for Issue 8 (The following changes make the wording for dup3() and pipe2() consistent with accept4().) Change: The dup3() function shall be equivalent to the dup2() function if the flag argument is 0, except that it shall be an error if fildes is equal to fildes2. Additionally, the flag argument can be constructed from a bitwise-inclusive OR of flags from the following list: to: The dup3() function shall be equivalent to the dup2() function, except that it shall be an error if fildes is equal to fildes2, and the state of FD_CLOEXEC and FD_CLOFORK on the fildes2 file descriptor shall be determined solely by the flag argument, which can be constructed from a bitwise-inclusive OR of flags from the following list: On page 1413 line 47116 section pipe(), change: The pipe2() function shall be equivalent to the pipe() function if the flag argument is 0. Additionally, the flag argument can be constructed from a bitwise-inclusive OR of flags from the following list (provided by ): to: The pipe2() function shall be equivalent to the pipe() function, except that the state of O_NONBLOCK on the new file descriptions and FD_CLOEXEC and FD_CLOFORK on the new file descriptors shall be determined solely by the flag argument, which can be constructed from a bitwise-inclusive OR of flags from the following list (provided by ): Next Steps ---------- The next calls are on: Mon 2022-05-02 (gettext) Thu 2022-05-05 (general bugs) Apologies in Advance: Geoff Clare, 2022-05-02, 2022-05-09 Andrew Josey, 2022-05-02 The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)