All
Enclosed are the minutes from the Monday meeting this week
regards
Andrew
---------
Minutes of the 25th March 2024 Teleconference Austin-1395 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 28th March 2024
Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Eric Blake, Red Hat, The Open Group OR
Eric Ackermann, CISPA
Geoff Clare, The Open Group
Apologies
Mark Ziegast, SHware Systemss Devs
* General news
A reminder that the US has switched to daylight saving time. The
meetings until April will be one hour earlier for attendees in
Europe.
We will not meet on April 1st.
The calls will continue on WEBEX for the moment.
* Current Business
1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797
We will continue this item next time that Paul is available (expected in April).
1798: Must posix_getdents remember file offsets across exec? Accepted as marked
https://austingroupbugs.net/view.php?id=1798
This item is tagged for TC1-2024
Proposed interpretation (review timer to start after approval of issue 8) using
Draft 4.0 line numbers
Interpretation response:
The standard states that the posix_getdents() function starts reading
at the current file offset in the open file description associated
with fildes, and conforming implementations must conform to this.
However, concerns have been raised about this which are being
referred to the sponsor.
Rationale:
Elsewhere the standard makes allowances for implementations where
directory streams are not implemented using a file descriptor, but
this was not extended to the new posix_getdents() function when it
was added.
Notes to the Editor (not part of this interpretation):
After page 920 line 31407 section fdopendir(), add a new paragraph:
If the file descriptor specified by fd is associated with an
open file description on which posix_getdents() has previously
been used, or for which any associated file descriptor is already
associated with a directory stream, the behavior is unspecified.
After page 1567 line 52616 section posix_getdents():
The behavior is unspecified if lseek() is used to set the file
offset to a value other than zero or a value returned by a
previous call to lseek() on the same open file description.
add these sentences:
The behavior is unspecified if calls to posix_getdents() are
made on different file descriptors that refer to the same open
file description (for example, before and after a file descriptor
is inherited across fork() or the exec family of functions, or
is duplicated using dup() or fcntl()), unless lseek() is used
to set the file offset to zero in between the calls to
posix_getdents(). A single exception to this condition is that
after a call to fork(), either the parent or child (but not
both) can continue processing the directory using posix_getdents().
Likewise, the behavior is unspecified if in between two calls
to posix_getdents() on one file descriptor, the file offset is
altered by a call made on a different file descriptor that
refers to the same open file description.
At page 1568 line 52626 section posix_getdents(), change:
If a sequence of calls to posix_getdents() is made that reads
from offset zero to end-of-file and a file is removed from or
added to the directory between the first and last of those
calls, whether the sequence of calls returns an entry for that
file is unspecified.
to:
If a sequence of calls to posix_getdents() is made that reads
from offset zero to end-of-file and a directory entry is removed
from or added to the directory between the first and last of
those calls, whether the sequence of calls returns that directory
entry is unspecified.
After page 1571 line 52771 section posix_getdents(), add a new paragraph to
RATIONALE:
The restrictions on the use of different file descriptors that
refer to the same open file description are needed in order to
enable implementations where directory streams are not implemented
using a file descriptor to maintain some internal state related
to a particular file descriptor.
At page 1858 line 61304, section readdir(), change:
If a file is removed from or added to the directory after the
most recent call to opendir() or rewinddir(), whether a subsequent
call to readdir() returns an entry for that file is unspecified.
to:
If a directory entry is removed from or added to the directory
after the most recent call to opendir() or rewinddir(), whether
a subsequent call to readdir() on that directory stream returns
that directory entry is unspecified. For all other directory
entries in the directory that existed at the time the directory
stream was opened or rewound and which have not been removed,
successive calls to readdir() on that directory stream shall
return each such directory entry exactly once before reporting
that the end of the directory has been reached, provided that
there are no intervening calls to seekdir() and no unspecified
behavior caused by performing an operation on an open file
description associated with the directory.
At page 1858 line 61319 section readdir(), change:
the result is undefined.
to:
the result is unspecified.
At page 1859 line 61332 section readdir(), change:
The readdir_r() function shall not return directory entries
containing empty names.
If a file is removed from or added to the directory after the
most recent call to opendir() or rewinddir(), whether a subsequent
call to readdir_r() returns an entry for that file is unspecified.
to:
The readdir_r() function shall not return directory entries
containing empty names. If entries for dot or dot-dot exist,
one entry shall be returned for dot and one entry shall be
returned for dot-dot; otherwise, they shall not be returned.
If a directory entry is removed from or added to the directory
after the most recent call to opendir() or rewinddir(), whether
a subsequent call to readdir_r() on that directory stream returns
that directory entry is unspecified. For all other directory
entries in the directory that existed at the time the directory
stream was opened or rewound and which have not been removed,
successive calls to readdir_r() on that directory stream shall
return each such directory entry exactly once before reporting
that the end of the directory has been reached, provided that
there are no intervening calls to seekdir() and no unspecified
behavior caused by performing an operation on an open file
description associated with the directory.
Bug 1801: xargs: add -P option
https://austingroupbugs.net/view.php?id=1801 Accepted as marked
This item is tagged for Issue 9.
On page 3600 line 123162 change:
[-s size] [utility [argument...]]
to:
[-P maxprocs] [-s size] [utility [argument...]]
On page 3600 line 123166 change:
The xargs utility shall then invoke the constructed command
line and wait for its completion.
to:
The xargs utility shall then invoke the constructed command
line and, if the -P maxprocs option is either not specified or
maxprocs is 1, wait for its completion.
After page 3600 line 123175 add a new paragraph:
If the -P maxprocs option is specified and maxprocs is greater
than 1, xargs shall wait for the completion of utility invocations
when necessary to limit the number of its unwaited-for child
processes to a maximum of maxprocs. When an end-of-file condition
is detected on standard input, xargs shall wait for the completion
of any remaining unwaited-for child processes. If repetition
of the sequence described above stops because an invocation's
exit status was 255, xargs shall wait for the completion of any
other invocations that it has executed and then exit as described
in CONSEQUENCES OF ERRORS.
After page 3601 line 123232 add:
-P maxprocs
Parallel mode: execute at most maxprocs invocations of
utility without waiting for any previous executions to
complete, then execute each additional invocation (if any)
after a previous execution has terminated. Specifying a
maxprocs value of 1 shall be equivalent to not specifying
the -P maxprocs option. If maxprocs is greater than 1, the
manner in which the arguments read from standard input are
distributed between the utility invocations is unspecified,
and the number of initial invocations of utility shall be
fewer than maxprocs only in the following circumstances:
All of the input arguments have been passed to executions
of utility without reaching the maxprocs limit.
The xargs utility is unable to create sufficient child
processes for the same reasons that the fork() function
would fail with [EAGAIN].
An implementation-defined limit is reached; this limit
shall be not less than the value of {_POSIX_CHILD_MAX}.
If the value of maxprocs is non-positive, the behavior is
unspecified.
After page 3603 line 123324 section xargs (CONSEQUENCES OF ERRORS), add a new
paragraph:
If xargs is unable to create a child process for the same
reasons that the fork() function would fail with [EAGAIN],
whether or not this is treated as an error depends on how
many unwaited-for child processes it has:
If xargs has at least one unwaited-for child process,
this condition shall not be treated as an error and
xargs shall wait for one of those child processes to
complete before another attempt to execute utility is
made.
If xargs has no unwaited-for child processes, this
condition shall be treated as an error.
On each attempt to execute utility, xargs may retry the
creation of a child process multiple times before deciding
that it is unable to do so.
Remove the FUTURE DIRECTIONS entry added by 0001811.
Bug 1806: ambiguous description of which attribtes `unset` unsets in case of
readonly attribute being set Accepted as Marked
https://austingroupbugs.net/view.php?id=1806
This item is tagged for TC1-2024 tag.
Proposed interpretation (review timer to start after approval of issue 8) ...
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 should not attempt to specify behavior for non-standard
variable attributes. An application which sets such an attribute
is using an extension, and the behavior of the extension is entirely
a matter for the implementation.
Notes to the Editor (not part of this interpretation):
On page 2571 line 83916-83923, replace the first four paragraphs of DESCRIPTION
with:
The unset utility shall unset a variable or function definition
specified by each name operand, as follows:
If −v is specified, name refers to a variable. If the named
variable exists and does not have the readonly attribute,
the shell shall unset it and shall remove the export attribute
if the variable has it. Read-only variables cannot be unset.
If −f is specified, name refers to a function. If the named
function exists, the shell shall unset the function definition.
If neither −f nor −v is specified and name refers to a
variable that exists, the variable shall be unset as if -v
was specified; if a variable by that name does not exist,
it is unspecified whether a function by that name, if any,
is unset.
On page 2573 line 83953, change:
All name operands were successfully unset.
to:
Each name operand either did not exist or was successfully unset.
Bug 0001805: ex: line breaks missing from command synopses Accepted
https://austingroupbugs.net/view.php?id=1805
We briefly looked at bug 1805 and Andrew took an action to address that one.
(addressed after the meeting)
Next Steps
----------
The next call is on:
Thu 2024-03-28 (WEBEX meeting - general bugs)
Mon 2024-04-01 No meeting
Thu 2024-04-04 (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)
--------
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
