Minutes of the 18th March 2019 Teleconference Austin-918 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 20th March 2019 Attendees: Mark Ziegast, SHware Systems Dev. Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Joerg Schilling, FOKUS Fraunhofer Eric Blake, Red Hat Geoff Clare, The Open Group Apologies Andrew Josey, The Open Group * General news None * 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 1199: strfmon, if standards compliant, produces highly misleading results Accepted as Marked http://austingroupbugs.net/view.php?id=1199 This item is tagged for Issue 8 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): On page 2039 line 65362 section strfmon(), change: + or ( Specify the style of representing positive and negative currency amounts. Only one of '+' or '(' may be specified. If '+' is specified, the locale's equivalent of '+' and '-' are used (for example, in many locales, the empty string if positive and '-' if negative). If '(' is specified, negative amounts are enclosed within parentheses. If neither flag is specified, the '+' style is used. to: + or ( Specify the style of representing positive and negative currency amounts. Only one of '+' or '(' can be specified. If '+' is specified, the locale's positive_sign and negative_sign values shall be used (for example, in many locales, the empty string if positive and '-' if negative). However, if both values would be returned by localeconv() as empty strings, strfmon() shall fail. The placement of the signs (if not empty) shall depend on the locale settings: * For the 'n' conversion specifier, the placement specified by the locale's p_sign_posn and n_sign_posn values shall be used. * For the 'i' conversion specifier, the placement specified by the locale's int_p_sign_posn and int_n_sign_posn values shall be used. If a sign's placement cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as 0 or {CHAR_MAX}, the sign shall be placed as if the relevant value was 1. If '(' is specified, negative amounts shall be enclosed within parentheses and the locale's positive_sign and negative_sign values shall not be used. If neither flag is specified, the style used shall depend on the locale settings: * For the 'n' conversion specifier, the style specified by the locale's p_sign_posn and n_sign_posn values shall be used. * For the 'i' conversion specifier, the style specified by the locale's int_p_sign_posn and int_n_sign_posn values shall be used. If the style cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as {CHAR_MAX}, the style used shall be that specified for the '+' flag; if this would cause strfmon() to fail because the locale's positive_sign and negative_sign values would both be returned by localeconv() as empty strings, strfmon() shall behave as if the negative_sign value was the string "-". On page 2041 line 65415 section strfmon(), change: If the total number of resulting bytes ... to: If all conversions are successful and the total number of resulting bytes ... On page 2041 line 65421 section strfmon(), add: [EINVAL] The '+' flag was included in a conversion specification and the locale's positive_sign and negative_sign values would both be returned by localeconv() as empty strings. On page 2042 line 65463 section strfmon(), change APPLICATION USAGE from: None. to: The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon() fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon() with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag. On page 2042 line 65465 section strfmon(), change RATIONALE from: None. to: The [EINVAL] error condition applies only when the '+' flag is used because this flag indicates that the application requires the use of signs, and if there are no signs in the locale data then this requirement cannot be satisfied. When neither '+' nor '(' is used, the application is requesting whatever formatting is appropriate for the locale, and so strfmon() has a fallback of using a '-' sign for negative values in cases where the locale data does not indicate parentheses should be used and has no signs. Cross-volume change to XBD ... On page 157 line 4931 section 7.3.3 LC_MONETARY, add: Certain combinations of the *_sign_posn, positive_sign and negative_sign values are invalid and shall not be accepted by localedef: * If p_sign_posn and n_sign_posn are both greater than 0, and positive_sign and negative_sign have the same value or are both either empty strings or omitted, this combination is invalid because it requires signs to be used but does not provide the means to distinguish negative from positive values using signs. * Likewise, if int_p_sign_posn and int_n_sign_posn are both greater than 0, and positive_sign and negative_sign have the same value or are both either empty strings or omitted, this combination is invalid. * If p_sign_posn and n_sign_posn are both 0, this combination is invalid because it requires parentheses to be used but does not provide the means to distinguish negative from positive values using parentheses. * Likewise, if int_p_sign_posn and int_n_sign_posn are both 0, this combination is invalid. Bug 1201: Atomicity requirements for sigsuspend Accepted as Marked http://austingroupbugs.net/view.php?id=1201 This item is tagged for TC3-2008 An interpretation is required. Interpretation response: The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The intention of the committee was to make this function atomic, but the wording did not make this clear. Notes to the Editor (not part of this interpretation): Change page 1984 lines 63848-63849 from: The sigsuspend( ) function shall replace the current signal mask of the calling thread with the set of signals pointed to by sigmask and then suspend the thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. to: The sigsuspend( ) function shall atomically both replace the current signal mask of the calling thread with the set of signals pointed to by sigmask and suspend the thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. Change on p1964 lines 63342-63343 The sigpause( ) function shall remove sig from the signal mask of the calling process and suspend the calling process until a signal is received. to: The sigpause( ) function shall atomically both remove sig from the signal mask of the calling process and suspend the calling process until a signal is delivered whose action is either to execute a signal-catching function or to terminate the process. Bug 1202: printf %.Nb with \c in arg (more than N chars into arg) behaviour unclear OPEN http://austingroupbugs.net/view.php?id=1202 We will continue on this item on the next call. Next Steps ---------- The next calls are on: March 21st 2019 (Thursday) This call will be for 90 minutes. Apologies in advance: Geoff Clare (2019-03-25) Calls are anchored on US time. (8am Pacific) All calls for the remainder of March will start an hour earlier than normal in Europe owing to the US change to daylight saving time. 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#