Minutes of the 11th August 2022 Teleconference Austin-1247 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 12th August 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Eric Ackermann, HPI, University of Potsdam Eric Blake, Red Hat, The Open Group OR Geoff Clare, The Open Group Andrew Josey, The Open Group Mark Ziegast, SHware Systems Dev. * General news This was a call dedicated to general bugs. * Current Business Bug 1122: POSIX should include gettext() and friends OPEN and https://posix.rhansen.org/p/gettext_draft Also https://austingroupbugs.net/file_download.php?file_id=64&type=bug Geoff's addition to XRAT appendix E was noted. A new PDF will be needed, but we will wait for more comments first. To be discussed again when more comments are raised. Bug 1560: clarify wording of command substitution https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561 and 1564 open awaiting reviews/discussion. Bug 1273: glob()'s GLOB_ERR/errfunc and non-directory files OPEN https://austingroupbugs.net/view.php?id=1273 We will leave this open awaiting feedback. Bug 768: add "fd-private" POSIX locks to spec OPEN https://austingroupbugs.net/view.php?id=768 Linux has now had OFD locks for several years, and more code in the wild is starting to use it - so we have existing practice (see note 2508) https://www.gnu.org/software/libc/manual/html_mono/libc.html#Open-File-Description-Locks Starting point of resolution at https://posix.rhansen.org/p/bug768 AI to EricB - take the GNU documentation and turn it into a desired action Bug 739: CX requirements for strftime seem to conflict with ISO C OPEN https://austingroupbugs.net/view.php?id=739 Nick completed his action to liaise with the C committee on this issue. C23 is about to go to ballot, so the way to raise the issue would be as a ballot comment. This could be done either as a UK or US national body comment, or another option might be for The Open Group to become a "category A" liaison to SC22. Bug 728: Restrictions on signal handlers are both excessive and insufficient OPEN https://austingroupbugs.net/view.php?id=728 The alignment with C17 changes the requirements in this area. There is still no allowance for accessing const objects or string literals, so that is something we could consider adding as an extension to C. Or we could raise the issue with the C committee if we want to stay in sync with the C standard. Suggestion: raise it as a C23 ballot comment. Depending on the answer, we could implement what they plan to do, or diverge (or leave things as they are). Bug 51: sh exit status not clear for built-in terminated by a signal Accepted as marked https://austingroupbugs.net/view.php?id=51 This item is tagged for Issue 8. An interpretation is required. AI: Andrew set interpretation timer. Interpretation response: The standard states the requirements for sh exit status, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: None. Notes to the Editor (not part of this interpretation): Page and line numbers are for Issue 8 draft 2.1. Changes to XBD... On page 372 line 12870 section , remove XSI shading from the SYNOPSIS. On page 372 line 12872-12876 section , add XSH shading to the PRIO_* constants and their introductory text. On page 372 line 12887-12890 section , add XSH shading to the RUSAGE_* constants and their introductory text. On page 372 line 12895-12898 section , add XSH shading to the text describing the rusage structure. On page 372 line 12899 section , add XSH shading to the text requiring the timeval structure to be defined. On page 372 line 12903 section , and page 373 line 12905 section , add XSI shading to RLIMIT_CPU and RLIMIT_FSIZE. On page 372 line 12911, 12913, 12914 section , add XSH shading to the declarations of getpriority(), getrusage(), and setpriority(). On page 372 line 12916 section , add XSH shading to the text requiring id_t to be defined. Changes to XSH... On page 1074 line 36699-36701 section getrlimit(), remove XSI shading from the SYNOPSIS. On page 1074 line 36724-36727 section getrlimit(), add XSI shading to RLIMIT_CPU. On page 1074 line 36731-36736 section getrlimit(), add XSI shading to RLIMIT_FSIZE. On page 1076 line 36789 section getrlimit(), add a new 1st paragraph to RATIONALE: These functions were previously part of the XSI option and have been moved to the Base so that portable shells, and other utilities that need to relay the wait status of a child process to a parent, can terminate themselves with the same signal that terminated the child but without overwriting a core image created by the child (through setting RLIMIT_CORE to zero, which disables core image creation). The RLIMIT_CPU and RLIMIT_FSIZE limits remain in the XSI option because they relate to other XSI functionality (SIGXCPU and SIGXFSZ). Changes to XCU... On page 2315 line 74583 section 2.5.2, change: Expands to the shortest representation of the decimal exit status of the pipeline (see ... to: Expands to the shortest representation of the decimal exit status (see [xref to 2.8.2]) of the pipeline (see ... On page 2331 line 75257 section 2.8.2, change: Otherwise, if the command terminated due to the receipt of a signal that was not caught, the exit status shall be greater than 128. Note that shell implementations are permitted to use an exit status greater than 255 if a command terminates due to a signal. to: Otherwise, if the command terminated due to the receipt of a signal, the shell shall assign it an exit status greater than 128. The exit status shall identify, in an implementation-defined manner, which signal terminated the command. Note that shell implementations are permitted to assign an exit status greater than 255 if a command terminates due to a signal. On page 2369 line 76716 section 2.14 (exit DESCRIPTION), change: The exit utility shall cause the shell to exit from its current execution environment with the exit status specified by the unsigned decimal integer n. If the current execution environment is a subshell environment, the shell shall exit from the subshell environment with the specified exit status and continue in the environment from which that subshell environment was invoked; otherwise, the shell utility shall terminate with the specified exit status. If n is specified, but its value is not between 0 and 255 inclusively, the exit status is undefined. to: The exit utility shall cause the shell to exit from its current execution environment. If the current execution environment is a subshell environment, the shell shall exit from the subshell environment and continue in the environment from which that subshell environment was invoked; otherwise, the shell utility shall terminate. The wait status of the shell or subshell shall be determined by the unsigned decimal integer n, if specified. If n is specified and has a value between 0 and 255 inclusive, the wait status of the shell or subshell shall indicate that it exited with exit status n. If n is specified and has a value greater than 256 that corresponds to an exit status the shell assigns to commands terminated by a valid signal (see [xref to 2.8.2 Exit Status for Commands]), the wait status of the shell or subshell shall indicate that it was terminated by that signal. No other actions associated with the signal, such as execution of trap actions or creation of a core image, shall be performed by the shell. If n is specified and is not an unsigned decimal integer, or has a value of 256, or has a value greater than 256 but not corresponding to an exit status the shell assigns to commands terminated by a valid signal, the wait status of the shell or subshell is unspecified. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when exit is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action. On page 2369 line 76747 section 2.14 (exit EXIT STATUS), change: The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when exit is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action. to: The exit utility causes the shell to exit from its current execution environment, and therefore does not itself return an exit status. On page 2370 line 76755 section 2.14 (exit APPLICATION USAGE), replace "None" with the text from the RATIONALE section at lines 76769-76773. On page 2370 line 76779 section 2.14 (exit RATIONALE), add a new paragraph: See also [xref to XRAT C.2.8.2]. On page 3155 line 107015 section sh (EXIT STATUS), change: Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke (see also the exit utility in [xref to 2.14]). to: Otherwise, the shell shall terminate in the same manner as for an exit command with no operands, unless the last command the shell invoked was executed without forking, in which case the wait status seen by the parent process of the shell shall be the wait status of the last command the shell invoked. See the exit utility in [xref to 2.14]. Change to XRAT... On page 3640 line 125987 section C.2.8.2, after: Implementations are encouraged to choose exit values greater than 256 to indicate programs that terminate by a signal so that the exit status cannot be confused with an exit status generated by a normal termination. append: However, the use of exit values greater than 256 poses a problem for the shell's own exit status. Historically this was the exit status of the last command invoked by the shell, but if the last command was terminated by a signal and was assigned an exit status greater than 256 by the shell, this value would be truncated to eight bits in the shell's exit status. Likewise truncation would occur with use of exit $? or ret=$? .... exit $ret in shell scripts. To avoid this truncation, shells which assign exit statuses greater than 256 are required to propagate the wait status of the last command to the shell's own wait status (by sending itself the same signal), and to handle exit values greater than 256 passed to the exit builtin by mimicking the wait status that would give rise to assignment of that exit status in the shell. Note that this requirement does not apply to signals that do not cause termination, such as SIGCHLD, since the shell can never actually assign a corresponding exit status greater than 256, and the requirement is worded in terms of this assignment. Bug 721: Internal storage vs static storage Dup of 1064 https://austingroupbugs.net/view.php?id=721 Bug 708: Make mblen, mbtowc, and wctomb thread-safe for alignment with C11 OPEN https://austingroupbugs.net/view.php?id=708 This was discussed with WG14: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_498 Here is the current wording in C23:
The behavior of the multibyte character functions is affected by the LC_CTYPE category of the current locale. For a state-dependent encoding, each of the mbtowc and wctomb functions is placed into its initial conversion state prior to the first call to the function and can be returned to that state by a call for which its character pointer argument, s, is a null pointer. Subsequent calls with s as other than a null pointer cause the internal conversion state of the function to be altered as necessary. It is implementation-defined whether internal conversion state has thread storage duration, and whether a newly created thread has the same state as the current thread at the time of creation, or the initial conversion state. A call with s as a null pointer causes these functions to return a nonzero value if encodings have state dependency, and zero otherwise. Changing the LC_CTYPE category causes the internal object describing the conversion state of the mbtowc and wctomb functions to have an indeterminate representation.
DR 498 (URL above) seems to have an agreed wording change from April 2017, but it has not been applied. AI: Nick to ask the WG14 convenor what happened to that DR. (completed during the meeting, but awaiting an answer) Bug 703: Add errno values for clock Accepted https://austingroupbugs.net/view.php?id=703 This item is tagged for T3-2008 Bug 700: Clarify strtoul's behaviour on strings representing negative numbers OPEN https://austingroupbugs.net/view.php?id=700 Continue on this item next time. Next Steps ---------- The next calls are on: Mon 2022-08-15 (general bugs) gettext is complete, but may be discussed again if comments are added Thu 2022-08-18 (general bugs) 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)