Minutes of the 5th September 2024 Teleconference    Austin-1426 Page 1 of 1
Submitted by Andrew Josey, The Open Group.        6th September 2024

Attendees:
   Andrew Josey, The Open Group
   Don Cragun, IEEE SA OR
   Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
   Eric Ackermann, CISPA
   Geoff Clare, The Open Group
   Tom Thompson, IEEE
   Eric Blake, Red Hat, The Open Group OR

Apologies
 None

* General news

It was agreed that we will cancel the meeting scheduled for September 12,
the next meeting will be September 19th.

We briefly mentioned the ISO status, which is unchanged  -- awaiting a reply
from the ISO editors. Andrew still has the action to prepare the revised frontmatter.


* Current Business

Bug 1851: FD_CLOFORK should not be preserved across exec
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1851

AI: Andrew to try to contact Solaris, other BSD, AIX, and macOS for comments.
Andrew has partially completed this, sending notes to contacts for Solaris and macOS.

Bug 1852: Clarify "$@[:$@:]" (with $# -eq 0) Accepted as Marked
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1852

There had been further discussion on the mailing list.
An interpretation is required.
This item is tagged for TC1-2024.

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:
The standard states "if the parameter being expanded was embedded
within a word, the first field shall be joined with the beginning
part of the original word and the last field shall be joined with
the end part of the original word." It is not clear how this applies
when there are no positional parameters as the "first field" and
"last field" do not exist in that case.

Notes to the Editor (not part of this interpretation):

On page 2479 line 80372 section 2.5.2, change:

    If one of these conditions is true, the initial fields shall
    be retained as separate fields, except that if the parameter
    being expanded was embedded within a word, the first field shall
    be joined with the beginning part of the original word and the
    last field shall be joined with the end part of the original
    word. In all other contexts the results of the expansion are
    unspecified. If there are no positional parameters, the expansion
    of '@' shall generate zero fields, even when '@' is within
    double-quotes; however, if the expansion is embedded within a
    word which contains one or more other parts that expand to a
    quoted null string, these null string(s) shall still produce
    an empty field, except that if the other parts are all within
    the same double-quotes as the '@', it is unspecified whether
    the result is zero fields or one empty field.
to:
    If one of these conditions is true, the initial fields (if any)
    shall be retained as separate fields, except that if the parameter
    being expanded was embedded within a word and either the beginning
    part (the part before the parameter being expanded) or the end
    part (the part after the parameter being expanded) of the
    original word was non-null:

	If there is at least one positional parameter, the first
	field shall be joined with the beginning part of the original
	word, or with the results of expansions already performed
	on it if there were any, and the last field shall be joined
	with the end part of the original word.

	If there are no positional parameters, the beginning part
	of the original word, or the results of expansions already
	performed on it if there were any, shall be joined with the
	end part of the original word.

    In all other contexts the results of the expansion are unspecified.
    If there are no positional parameters and the parameter being
    expanded was not embedded in a word with other parts whose
    expansion is non-null, the expansion of '@' shall generate zero
    fields, even when '@' is within double-quotes; however, if the
    expansion is embedded within a word which contains one or more
    other parts that expand to a quoted null string, these null
    string(s) shall still produce an empty field, except that if
    the other parts are all within the same double-quotes as the
    '@', it is unspecified whether the result is zero fields or one
    empty field.

On XRAT page 3877 line 134466 section C.2.5.2, change:
    printf '[%s]\n' foo $@
    [foo]
    printf '[%s]\n' foo "$@"
    [foo]
    printf '[%s]\n' foo ''$@
    [foo]
    []
    printf '[%s]\n' foo ''"$@"
    [foo]
    []
    printf '[%s]\n' foo "$novar$@$(echo)"
    [foo]
    [] </tt>(this line of output is optional)<tt>
    printf '[%s]\n' foo ''"$novar$@$(echo)"
    [foo]
    []

to:
    printf '[%s]\n' foo $@
    [foo]
    printf '[%s]\n' foo a$@
    [foo]
    [a]
    printf '[%s]\n' foo "$@"
    [foo]
    printf '[%s]\n' foo "$@b"
    [foo]
    [b]
    printf '[%s]\n' foo "$@$@"
    [foo]
    printf '[%s]\n' foo "$@""$@"
    [foo]
    printf '[%s]\n' foo "$@$*"
    [foo]
    [] </tt>(this line of output is optional)<tt>
    printf '[%s]\n' foo "$@""$*"
    [foo]
    []
    printf '[%s]\n' foo ''$@
    [foo]
    []
    printf '[%s]\n' foo ''"$@"
    [foo]
    []
    printf '[%s]\n' foo "$novar$@$(echo)"
    [foo]
    [] </tt>(this line of output is optional)<tt>
    printf '[%s]\n' foo ''"$novar$@$(echo)"
    [foo]
    []


Bug 1853: xargs -x lost an important detail between Issue 6 and 7 Accepted
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1853

This item is tagged for TC1-2024.

Bug 1854: dd iflags=fullblock should be iflag=fullblock OPEN
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1854

We discussed this issue, which appears to be a typo in the standard. We are looking for advice
from IEEE on whether this can be handled as an errata item (iflags should have been iflag).


Bug 1797: strftime "%s" should be able to examine tm_gmtoff
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

Nick reported feedback on continuing discussions with the ISO C
committee on this item, together with the response from Paul Eggert (posted to the etherpad).
We have a few weeks to respond before the next ISO C meeting.

Next Steps 
----------

The next calls are on
 (Thu 2024-09-12 Canceled)
 Thu 2024-09-19 (WEBEX meeting - 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)