Minutes of the 6th June 2019 Teleconference Austin-941 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 7th June 2019 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Don Cragun, IEEE PASC OR Geoff Clare, The Open Group Joerg Schilling, FOKUS Fraunhofer Mark Ziegast, SHware Systems Dev. Eric Blake, Red Hat, The Open Group OR * General news There was no new status on the PAR and PMC approvals at the PASC SEC. We reminded those on this call to respond if they are on the PASC SEC. After the call, four approvals had been received. The comment period runs until June 17. * 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. Bug 1218: Add reallocarray() OPEN http://austingroupbugs.net/view.php?id=1218 Action: Eric to ask if The Open Group is willing to sponsor this interface. A full set of changes would need to be developed. Bug 1219: snprintf requirement to fail when n > INT_MAX conflicts with C OPEN http://austingroupbugs.net/view.php?id=1219 Action: Nick (on his return) to ask C committee for guidance, whether an n > INT_MAX but less than SIZE_MAX, where SIZE_MAX is between, inclusively, INT_MAX+1 and UINT_MAX (or higher on 64-bit architectures) may be a preemptive reason to fail the interface, without examining any other arguments. Bug 1220: Add an API to query the name of a locale category of a locale object OPEN http://austingroupbugs.net/view.php?id=1220 Action: Eric to ask if The Open Group is willing to sponsor this interface. * Current Business Bug 1229: EXIT_FAILURE should not be allowed to be all non-zero values Accepted as marked. http://austingroupbugs.net/bug_view_page.php?bug_id=1229 This item is tagged for TC3-2008. An interpretation is requird. 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 ISO C standard requires that exit(EXIT_FAILURE) returns ``unsuccessful termination status'' to the host environment. In a POSIX host environment this means that the lower 8 bits of EXIT_FAILURE must have at least one bit set. Notes to the Editor (not part of this interpretation): Make the changes in Note: 0004269 Revised proposal: On page 359 line 12240 section , change: EXIT_FAILURE Unsuccessful termination for exit(); evaluates to a non-zero value EXIT_SUCCESS Successful termination for exit(); evaluates to 0. to: EXIT_FAILURE Unsuccessful termination for exit(); [CX]the value shall be between 1 and 125 inclusive[/CX]. EXIT_SUCCESS Successful termination for exit(); the value shall be 0. On page 361 line 12340 section , change RATIONALE from: None. to: The ISO C standard requires that exit(EXIT_FAILURE) returns ``unsuccessful termination status'' to the host environment. In a POSIX host environment this means that the lower 8 bits of EXIT_FAILURE must have at least one bit set. The standard developers decided to further restrict the allowed values for the following reasons: Exit statuses of 126, 127, and greater than 128 are ambiguous in certain circumstances because they have special meanings in the shell (see [xref to XCU 2.8.2 Exit Status for Commands]). The xargs utility quits when a command execution exits with status 255 (see [xref to XCU xargs]). Calling exit() with a value greater than 255 or less than 0 is something that only programs which are specifically designed to have their exit status obtained by waitid() should do (since it does not truncate the exit status to 8 bits). ``Pure ISO C'' programs that call exit(EXIT_FAILURE) do not meet this design criterion. The value 128 is disallowed for simplicity, making the allowed values 1 to 125 inclusive rather than 1 to 125 inclusive and 128. The requirement that the value of EXIT_SUCCESS is 0 is not shaded CX because this matches the requirement in the ISO C standard that exit(EXIT_SUCCESS) returns ``successful termination status'' to the host environment (when the host environment is a POSIX implementation). Bug 1231: backslash processing in text arguments Accepted as Marked http://austingroupbugs.net/view.php?id=1231 This item is tagged for TC3-2008 An interpretation is required Interpretation response: The standard states the requirements for handling in text arguments, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The standard does not match some existing practice. Notes to the Editor (not part of this interpretation): Change: The argument text shall consist of one or more lines. Each embedded in the text shall be preceded by a . Other characters in text shall be removed, and the following character shall be treated literally. to: The argument text shall consist of one or more lines. A in the text can be escaped with another . The application shall ensure that each embedded (that is, those other than the terminating of the last line) in the text is preceded by an unescaped . The behaviour is unspecified if an unescaped is immediately followed by any character other than or , or by the end of a script. Bug 1232: redirection to wildcard that match more than one word OPEN http://austingroupbugs.net/view.php?id=1232 We started on this item and will continue next time Next Steps ---------- The next calls are on: June 10 2019 (Monday) This call will be for 60 minutes. June 13 2019 (Thursday) This call will be for 90 minutes. Calls are anchored on US time. (8am Pacific) Please check the calendar invites for new dial in details. 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#