Minutes of the 10th August 2023 Teleconference Austin-1336 Page 1 of 1 Submitted by Geoff Clare, The Open Group. 10th August 2023 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Eric Ackermann, HPI, University of Potsdam Geoff Clare, The Open Group Eric Blake, Red Hat, The Open Group OR Mark Ziegast, SHware Systems Dev. Apologies Andrew Josey, The Open Group * General news None * Current Business Note for issue resolution all items are tagged for Issue 8 unless noted otherwise or disposition is reject or duplicate. Bug 1273: glob()'s GLOB_ERR/errfunc and non-directory files Accepted as marked https://austingroupbugs.net/view.php?id=1273 This item is tagged for TC3-2008. An interpretation is required. 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: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Page and line numbers are for Issue 8 draft 3. On page 1201 line 41070 section glob() (GLOB_ERR), change: Cause glob() to return when an attempt to open, read, or search a directory fails because of an error condition that is related to file system contents. If this flag is not set, glob() shall not treat such conditions as an error, and shall continue to look for matches. Other error conditions may also be treated the same way as error conditions that are related to file system contents. to: Cause glob() to return when an attempt to open or search a pathname as a directory, or an attempt to read an opened directory, fails because of an error condition that is related to file system contents and prevents glob() from expanding the pattern. If this flag is not set, glob() shall not treat such conditions as an error, and shall continue to look for matches. Other error conditions may also be treated the same way as error conditions that are related to file system contents. On Issue 8 draft 3 page 1202 line 41114 section glob(), change: If, during the search, an attempt to open, read, or search a directory fails and errfunc is not a null pointer, ... to: If errfunc is not a null pointer and, during the search, an attempt to open or search a pathname as a directory, or an attempt to read an opened directory, fails because of an error condition that prevents glob() from expanding the pattern, ... After page 1203 line 41124 section glob(), add a paragraph: The set of error conditions that are considered to prevent glob() from expanding the pattern shall include [EACCES], [ENAMETOOLONG], and [ELOOP]. It is implementation-defined what other error conditions are included in the set. After page 1204 line 41202 section glob() (RATIONALE), add: Implementations differ as to which error conditions they consider prevent glob() from expanding the pattern. The standard requires that [EACCES], [ENAMETOOLONG], and [ELOOP] are included because in these cases the expansion could succeed if performed with a different effective user or group ID, or with an alternative pathname (shorter than {PATH_MAX}, or traversing fewer symbolic links). Implementations are encouraged to call (*errfunc()) for all error conditions that are related to file system contents which occur when attempting to open or search a pathname as a directory or attempting to read an opened directory. The appropriate way to handle such errors varies according to the provenance of the pattern and what the application will do with the resulting pathnames, and should therefore be for the application to decide. For example, given the pattern "non-existing/*", some applications may want glob() to succeed and return an empty list because there are no existing files that match the pattern, but for others that would not be appropriate, such as if an application asks the user to name a directory containing files to be processed and the user makes a typing mistake when responding; the application will want to alert the user to the mistake instead of behaving as if the user had named an empty directory. If (*errfunc()) is called for [ENOENT] errors, the first application can ignore them in that function, but if (*errfunc()) is not called, the second application cannot achieve what it wants using glob(). Similar reasoning applies for the pattern "regular_file/*" and [ENOTDIR] errors. On page 1205 line 41217 section glob(), change FUTURE DIRECTIONS from "None" to: A future version of this standard may require that (*errfunc()) is called for all error conditions that are related to file system contents which occur when attempting to open or search a pathname as a directory or attempting to read an opened directory. On page 2508 line 81856 section 2.14.3, change: If these permissions are denied, or if an attempt to open or search a directory fails because of an error condition that is related to file system contents, this shall not be considered an error and pathname expansion shall continue as if the directory had existed and had been successfully opened or searched, and no matching directory entries had been found in it. to: If these permissions are denied, or if an attempt to open or search a pathname as a directory, or an attempt to read an opened directory, fails because of an error condition that is related to file system contents, this shall not be considered an error and pathname expansion shall continue as if the pathname had named an existing directory which had been successfully opened and read, or searched, and no matching directory entries had been found in it. Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer size OPEN https://austingroupbugs.net/view.php?id=1406 We are still waiting for input. Bug 657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN https://austingroupbugs.net/view.php?id=657 Eric B. has an outstanding action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. Bug 864: Insufficient specification of storage requirements for synchronization objects OPEN https://www.austingroupbugs.net/view.php?id=864 This was discussed again in the August 10, 2023 teleconference. Items 2 and 3 could perhaps be dealt with by adding more text to section 2.9.9, but we still need proposed wording. Bug 689: Possibly unintended allowance for stdio deadlock Accepted as marked https://www.austingroupbugs.net/view.php?id=689 An interpretation is required. Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- There are possible deadlocks in multi-threaded applications that were not considered when POSIX added support for threading. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- After Issue 8 draft 3 page 520 line 18489 section 2.5: All functions that read, write, position, or query the position of a stream, except those with names ending _unlocked, shall lock the stream as if by a call to flockfile( ) before accessing it and release the lock as if by a call to funlockfile( ) when the access is complete. add: [CX]If the lock is not immediately available, the function shall wait for it to become available, except in the following circumstances. If the stream is line buffered and is open for writing or for update, and the reason the function is attempting to lock the stream is because it is going to request input on another stream that is unbuffered, or is line buffered and requires the transmission of characters from the host environment (see above), then the function shall attempt to determine whether a deadlock situation exists. If a deadlock situation is found to exist, the function shall fail. If the function is able to establish that a deadlock situation does not exist, it shall wait for the lock to become available. If the function does not establish whether or not a deadlock situation exists, it shall continue as if it had already locked the stream, found its buffer to be empty, and released the lock.[/CX] Action: Andrew to start the interpretation review for bugs 689 and 1273. Next Steps ---------- The next call is on: Mon 2023-08-14 (Zoom meeting - general bugs/ballot resolution) Thu 2023-08-17 (Zoom meeting - general bugs/ballot resolution) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Apologies in advance: Tom Thompson 2023-08-14 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)