Minutes of the 27th February 2025 Teleconference Austin-1446 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 1 March 2025 Attendees: Don Cragun, IEEE SA OR Andrew Josey, The Open Group Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Eric Ackermann, CISPA Eric Blake, Red Hat, The Open Group OR Geoff Clare, The Open Group Mark Brown Apologies Tom Thompson, IEEE We briefly discussed the status of the Mantis update for austingroupbugs.net, and agreed that the switch over had been successful and any minor issues that may come to light can be addressed if necessary. We confirmed the calendar for upcoming meetings, adding a meeting on March 13th. Please note that the US adjusts its clocks on March 9th so the call will be one hour earlier in Europe for a couple of weeks. * Open Business Bug 1876: clarify, whether a trap action that is executed from a OPEN context where set -e is ignored, would have set -e ignored, too https://www.austingroupbugs.net/bug_view_page.php?bug_id=1876 Andrew took an action to ask shell developers to comment on this issue. (completed by sending an email to the reflector: austin-group-l:archive/latest/37925). Bug 864: Insufficient specification of storage requirements for synchronization objects https://www.austingroupbugs.net/view.php?id=864 We discussed this item that had been tabled until Issue 8 TC 1. AI: Andrew to contact Rich Felker to determine whether or not items 1 an 4 have been resolved by section 2.9.9 and to get suggested wording for changes to address items 2 and 3. The action was completed, but no response received as yet. Bug 1904: LC_TIME era start_date (and end_date) possibly mis-specified https://www.austingroupbugs.net/bug_view_page.php?bug_id=1904 This was discussed during the 2025-02-13 meeting: Historically, there was no year 0 and the standard is worded to reflect this fact. Is this what implementation actually do? Andrew had completion an action to ask for input on what other implementations do and some feedback has been received so need to return to this on a future call. Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 We reviewed the proposals in the bug. A.I. Eric B: Flesh out the text in the bug report for a fully developed man page. We also need to come back to this one. * Current Business No new bugs had been received as the bug tracker had been down for the maintenance update. We spent the meeting discussing a liaison question from Dave Banham in the ISO C group. "I am wondering what the Austin Groups position is on the paper N3401 “SIGFPE and I/O, version 2” (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3401.htm) is? My concern is that it seems to suggest that SIGFPE cannot arise as a result of domain errors in the math and I/O functions. Part of the problem seems to be that whilst the C Standard defines the SIGFPE signal is does not indicate what the default signal handling behaviour is, nor whether floating point exceptions can actually result in a SIGFPE signal. And I note that the typical function for enabling this is feenableexcept(), which lies outside of the POSIX standard's scope too. Thoughts?" Of the proposal in N3401, option 3 seems the most reasonable to the Austin Group; however, POSIX follows the C standard, and will continue to do so. It is noted that many Linux, BSD and other systems do support the feenableexcept() mechanism to request SIGFPE for certain conditions, and these systems do raise a SIGFPE from these library functions. Next Steps ---------- The next calls are on Thu 2025-03-06 (WEBEX meeting - general bugs) Thu 2025-03-13 (WEBEX meeting - general bugs) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Apologies in advance Eric Blake, 2025-03-13 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)