Minutes of the 11th May 2023 Teleconference    Austin-1309 Page 1 of 1
Submitted by Andrew Josey, The Open Group.         13th May 2023

Attendees:
    Don Cragun,  IEEE PASC OR
    Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
    Andrew Josey, The Open Group
    Geoff Clare, The Open Group
    Eric Blake, Red Hat, The Open Group OR
    Mark Ziegast, SHware Systems Dev.

Apologies
    Eric Ackermann, HPI, University of Potsdam
    Tom Thompson, IEEE

* General news

A reminder that we have switched to meeting once per week (on Thursdays)
while the current ballot is in progress, that is until June.

The IEEE ballot status is  basically unchanged since last time, we have 4 comments received to date (2 editorial, 2 technical), with a return rate of 61% (11 ballots out of 18 received). The ballot closes on 30 May 2023.

Andrew took an action to check with Tom whether we are able to send
a reminder to members of the ballot group.


This section trimmed -- see Austin/1306


* Current Business

We started by discussing the C23 status, as we had received a
reminder from Joseph Meyers to provide input.

We discussed three bug reports and Nick took an action,
completed after the meeting, to submit to Joseph.
They are recorded in the document register as document Austin/1310.


Bug 1644: void * to function pointer is described in annex J of C standard (informative).
https://austingroupbugs.net/view.php?id=1644

Accepted as marked.

This item is tagged for TC3-2008.

On page 746 line 25418 section dlsym(), change:
    <blockquote>cast to a pointer to the type of the named symbol</blockquote>
to:
    <blockquote>converted from type pointer to <b>void</b> to a
    pointer to the type of the named symbol</blockquote>


Bug 1645: execvp( ) requirements on arg0 are too strict Accepted as Marked
https://austingroupbugs.net/view.php?id=1645

This item is tagged for TC3-2008.

An interpretation is required.
Action on Andrew to start the timer (completed after the meeting).

Interpretation response:
The standard states the value of arg0 to be passed to the sh utility,
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, and a different
arg0 value is not observable by applications (without using
extensions).

Notes to the Editor (not part of this interpretation):
At page 784 lines 26552-26557 (XSH exec DESCRIPTION), change:
    ...the executed command shall be as if the process invoked the sh utility using execl( ) as follows:
    <tt>execl(<shell path>, arg0, file, arg1, ..., (char *)0);</tt>
    where <shell path> is an unspecified pathname for the sh utility,
    file is the process image file, and for execvp( ), where arg0,
    arg1, and so on correspond to the values passed to execvp( )
    in argv[0], argv[1], and so on.

to:
    ...the executed command shall be as if the process invoked the sh utility using execl( ) as follows:
    <tt>execl(<shell path>, <name>, file, <args>, (char *)0);</tt>
    where <shell path> is an unspecified pathname for the sh utility,
    <name> is an unspecified string, file is the process image file,
    and where <args> is zero or more parameters corresponding to
    any initial non-null arguments passed after arg0 for execlp( )
    or to any initial non-null members of argv starting at argv[1]
    for execvp( ).


After page 794 line 26981 (XSH exec RATIONALE), add a new paragraph:
    When execlp( ) or execvp( ) fall back to invoking sh because
    of an ENOEXEC condition, the standard leaves the process name
    (what becomes argv[0] in the resulting sh process) unspecified.
    Existing implementations vary on whether they pass a variation
    of "sh", or preserve the original arg0. There are existing
    implementations of sh that behave differently depending on the
    contents of argv[0], such that blindly passing the original
    arg0 on to the fallback execution can fail to invoke a compliant
    shell environment. Because of the requirements on how sh handles
    its command line arguments, the shell script will see $0
    containing the pathname of the script being executed, regardless
    of the value of argv[0].


Bug 1674: may posix_spawnp() fail with ENOEXEC?
https://austingroupbugs.net/view.php?id=1674

We will start on this item next time.


Next Steps
----------
The next call is on:
   Thu 2023-05-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)