hi all
Enclosed are the minutes of the thursday meeting this week
regards
Andrew
-----------
Minutes of the 21st March 2024 Teleconference Austin-1394 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 24th 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
Mark Ziegast, SHware Systemss Dev.
Geoff Clare, The Open Group
* General news
The calls will continue on WEBEX for the moment.
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.
* 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.
Paul apologized for not making the 21st, and it now looks like it will
be April before he can next join.
1798: Must posix_getdents remember file offsets across exec? Reopened
https://austingroupbugs.net/view.php?id=1798
Although closed previously, we reopened the bug and continued the discussion
from the
previous meeting, and proposed a revised resolution (line numbers from draft 4):
Proposed interpretation (review timer to start after approval of issue 8) ...
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.
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 61312, 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 file 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
an entry for that file is unspecified. For all other files in
the directory that existed at the time the directory stream was
opened and which have not been removed, successive calls to
readdir( ) on that directory stream shall return an entry for
each such file 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 opening a second directory stream on the same file
description associated with the directory. For any such file
that is renamed within the directory after the directory stream
was opened, readdir( ) shall return either an entry for the
original name or for the new name, but not both.
At page 1858 line 61319 section readdir(), change:
the result is undefined.
to:
the result is unspecified.
Bug 1803: Many non-ASCII characters display incorrectly Accepted
https://austingroupbugs.net/view.php?id=1803
We briefly looked at bug 1803 and Andrew took an action to address that one.
(addressed after the meeting)
Next Steps
----------
The next call is on:
Mon 2024-03-25 (WEBEX meeting - general bugs)
Thu 2024-03-28 (WEBEX meeting - general bugs)
No meeting on April 1st.
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: [email protected]
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
