All
Enclosed are the minutes of the Thursday call this week
regards
Andrew
----------------
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 <sys/resource.h>, remove XSI shading from the
SYNOPSIS.
On page 372 line 12872-12876 section <sys/resource.h>, add XSH shading to the
PRIO_* constants and their introductory text.
On page 372 line 12887-12890 section <sys/resource.h>, add XSH shading to the
RUSAGE_* constants and their introductory text.
On page 372 line 12895-12898 section <sys/resource.h>, add XSH shading to the
text describing the rusage structure.
On page 372 line 12899 section <sys/resource.h>, add XSH shading to the text
requiring the timeval structure to be defined.
On page 372 line 12903 section <sys/resource.h>, and
page 373 line 12905 section <sys/resource.h>, add XSI shading to RLIMIT_CPU and
RLIMIT_FSIZE.
On page 372 line 12911, 12913, 12914 section <sys/resource.h>, add XSH shading
to the declarations of getpriority(), getrusage(), and setpriority().
On page 372 line 12916 section <sys/resource.h>, 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:
<blockquote>
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.
</blockquote>
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)
--------
Andrew Josey The Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
To learn how we maintain your privacy, please review The Open Group Privacy
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub&listid=2481
