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)