All Enclosed are the minutes of the thursday meeting regards Andrew ------------------ Minutes of the 26th September 2024 Teleconference Austin-1428 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 28th September 2024
Attendees: Andrew Josey, The Open Group Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE SA OR Eric Ackermann, CISPA Geoff Clare, The Open Group Eric Blake, Red Hat, The Open Group OR Apologies Tom Thompson, IEEE * General news We discussed the ISO status-- we are still awaiting a reply from the ISO editors. Andrew had attended the SC22 meeting in London on Monday 23rd and had presented the Austin Group/9945 Project Editor status. He had also spoken with Bill Ash and David Keaton about the status of draft approval. We hope to have a response from ISO within a few weeks. Andrew had also spoken with IEEE about a possible fallback path to ISO, which is via the IEEE PSDO process. This was a positive call and remains a possibility. An issue of duplicate emails to the reflector was raised. It appears some emails triggered by Mantis bug reports are being delivered multiple times, with a delay between (for example one was repeated 6 days after). This seems to be an increasing problem. Andrew will contact Mark Brown to see if there is anything we can do - initial investigations show it to be at the Mantis side rather than The Open Group receiving email system (the items has different message IDs). * Current Business Bug 1851: FD_CLOFORK should not be preserved across exec https://www.austingroupbugs.net/bug_view_page.php?bug_id=1851 This item still open. AI: Andrew to try to contact Solaris, other BSD, AIX, and macOS for comments. Andrew has partially completed this, sending notes to contacts for Solaris and macOS. A response has been received for Solaris. Bug 1797: strftime "%s" should be able to examine tm_gmtoff OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1797 This item is still open. Bug 1854: dd iflags=fullblock should be iflag=fullblock OPEN https://www.austingroupbugs.net/bug_view_page.php?bug_id=1854 This item still open On this issue, which appears to be a typo in the standard. We are looking for advice from IEEE on whether this can be handled as an errata item (iflags should have been iflag). Bug 1855: Use of freopen with different kinds of streams Accepted as Marked https://www.austingroupbugs.net/bug_view_page.php?bug_id=1855 This item is tagged for TC1-2024. An interpretation is requird. Interpretation response: Regarding the use of freopen() with a non-null pathname, the standard clearly states that freopen() first attempts to flush the stream then closes any file descriptor associated with the stream, and conforming implementations must conform to this. Regarding the use of freopen() with a null pathname on a stream that has an associated file descriptor, the standard clearly states that the file descriptor associated with the stream need not be closed if the call to freopen() succeeds and that it is implementation-defined which changes of mode are permitted (if any), and under what circumstances, and conforming implementations must conform to this. Regarding the use of freopen() with a null pathname on a stream that does not have an associated file descriptor, 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: There are unusual but valid use cases where a stream opened with popen() would not be closed with pclose(), such as forking after popen() and using fclose() or freopen() on the stream in the child. Another use case would be if an application wants to be able to detect that the child started by popen() was stopped by a signal. It would need to find out the process ID by some means (e.g. read it from the stream) but it could then call waitpid() and either fclose() or freopen() instead of using pclose(). On memory streams, with a non-null pathname the standard uses "if any" in the stated requirement about an associated file descriptor. However, with a null pathname there are references to the associated file descriptor which assume there is one. Notes to the Editor (not part of this interpretation): On page 1030 line 35294 section freopen(), change: In this case, the file descriptor associated with the stream need not be closed if the call to freopen() succeeds. to: In this case, if there is a file descriptor associated with the stream, it need not be closed if the call to freopen() succeeds. On page 1030 line 35313 section freopen(), change: The file descriptor underlying the stream is not a valid file descriptor when pathname is a null pointer. to: The file descriptor associated with the stream, if any, is not a valid file descriptor when pathname is a null pointer. On page 1031 line 35351 section freopen(), change: The mode with which the file descriptor underlying the stream was opened does not support the requested mode when pathname is a null pointer. to: The mode with which the file descriptor associated with the stream, if any, was opened does not support the requested mode when pathname is a null pointer. After page 1032 line 35390 section freopen(), add a paragraph to APPLICATION USAGE: The use of freopen() on streams opened with open_memstream() or open_wmemstream() is discouraged, as some of the requirements stated in the description of those functions are conditional on there having been a successful fflush() or fclose() on the stream. These cannot be relied upon if freopen() is used (without first doing an explicit fflush()) because freopen() ignores failure of the flush operation. Bug 1856: 0001856: FLT_MIN formula is b^{e_{\min-1}} instead of b^{e_{\min}-1} Accept https://www.austingroupbugs.net/bug_view_page.php?bug_id=1856 This is an online publications bug with rendering the formula in float.h. Andrew took an action to correct this (completed after the meeting). (note we skipped 1857 as being discussed on the mailing list) Bug 1858: open_memstream() doesn't say where the result lies OPEN https://www.austingroupbugs.net/bug_view_page.php?bug_id=1858 We started on this item and will continue next time. Next Steps ---------- The next calls are on Thu 2024-10-03 (WEBEX meeting - general bugs) Thu 2024-10-10 (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: [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
