Minutes of the 1st September 2022 Teleconference Austin-1252 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 1st September 2022 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 Andrew Josey, The Open Group Tom Thompson, IEEE * General news This was a call dedicated to general bugs. As a reminder we agreed previously that there will be NO meeting 2022-09-05 (due to the holiday in the US). * Current Business Bug 1122: POSIX should include gettext() and friends OPEN and https://posix.rhansen.org/p/gettext_draft Also https://austingroupbugs.net/file_download.php?file_id=64&type=bug Geoff's addition to XRAT appendix E and cancellation points lists have been noted to date. A new PDF will be needed, but we will continue to wait for more comments first. To be discussed again when more comments are raised. Bug 1560: clarify wording of command substitution https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561 and 1564 open awaiting reviews/discussion. Bug 1273: glob()'s GLOB_ERR/errfunc and non-directory files OPEN https://austingroupbugs.net/view.php?id=1273 We will leave this open awaiting feedback. Bug 768: add "fd-private" POSIX locks to spec OPEN https://austingroupbugs.net/view.php?id=768 Linux has now had OFD locks for several years, and more code in the wild is starting to use it - so we have existing practice (see note 2508) https://www.gnu.org/software/libc/manual/html_mono/libc.html#Open-File-Description-Locks Starting point of resolution at https://posix.rhansen.org/p/bug768 AI to EricB - take the GNU documentation and turn it into a desired action Bug 739: CX requirements for strftime seem to conflict with ISO C OPEN https://austingroupbugs.net/view.php?id=739 Nick completed his action to liaise with the C committee on this issue. C23 is about to go to ballot, so the way to raise the issue would be as a ballot comment. This could be done either as a UK or US national body comment. Andrew confirmed with the UK C Panel that we can submit comments. Bug 728: Restrictions on signal handlers are both excessive and insufficient OPEN https://austingroupbugs.net/view.php?id=728 The alignment with C17 changes the requirements in this area. There is still no allowance for accessing const objects or string literals, so that is something we could consider adding as an extension to C. Or we could raise the issue with the C committee if we want to stay in sync with the C standard. Suggestion: raise it as a C23 ballot comment. Depending on the answer, we could implement what they plan to do, or diverge (or leave things as they are). AI Nick and Geoff: File ballot comments on C23 (through the US and/or UK national bodies to WG14). Bug 708: Make mblen, mbtowc, and wctomb thread-safe for alignment with C11 OPEN https://austingroupbugs.net/view.php?id=708 This was discussed with WG14: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_498 DR 498 (URL above) seems to have an agreed wording change from April 2017, but it has not been applied. Nick asked the WG14 convenor what happened to that DR. It appears the item was discussed but in the end the C committee could not agree an acceptable change, and no alternate proposal was available. We will need to accept the C wording for now. Bug 700: Clarify strtoul's behaviour on strings representing negative numbers OPEN https://austingroupbugs.net/view.php?id=700 AI: Nick and Geoff to work together on a C23 ballot comment (against N3047 7.24.1.7 para 5). Bug 689: Possibly unintended allowance for stdio deadlock OPEN https://austingroupbugs.net/view.php?id=689 Change needs to be coordinated with C23. AI: Nick and Geoff to work together on a C23 ballot comment (against N3047 7.23.3 para 3). Bug 618: require isatty and friends to set errno on failure OPEN https://austingroupbugs.net/view.php?id=618 Action item to EricB: email to various lists to collect results for sample program (see bug 503 comment 1005 for starting point) for current errno behavior on various OS Bug 609: It is not clear what threads are considered blocked with respect to a call to pthread_cond_signal() or pthread_cond_broadcast() Accepted as Marked https://austingroupbugs.net/view.php?id=609 This item is tagged for TC3-2008. An interpretation is required. Interpretation response: The standard clearly states that pthread_cond_broadcast() unblocks all of the threads, and pthread_cond_signal() unblocks at least one of the threads, that are currently blocked on the specified condition variable, and conforming implementations must conform to this. Rationale: Although the word "currently" is imprecise about when exactly the set of threads blocked on cond is determined, it is clear that this point must be during the call to pthread_cond_broadcast() or pthread_cond_signal(). Therefore threads which become blocked after the call has returned must not be unblocked by the call. Notes to the Editor (not part of this interpretation): At line 50746 change: The pthread_cond_broadcast() function shall unblock all threads currently blocked on the specified condition variable cond. The pthread_cond_signal() function shall unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond). to: The pthread_cond_broadcast() function shall, as a single atomic operation, determine which threads, if any, are blocked on the specified condition variable cond and unblock all of these threads. The pthread_cond_signal() function shall, as a single atomic operation, determine which threads, if any, are blocked on the specified condition variable cond and unblock at least one of these threads. At line 50762 change: The pthread_cond_broadcast() and pthread_cond_signal() functions shall have no effect if there are no threads currently blocked on cond. to: The pthread_cond_broadcast() and pthread_cond_signal() functions shall have no effect if they determine that there are no threads blocked on cond. Note to the editor: In Issue 8, after applying bug 1302, make equivalent changes to the cnd_broadcast() page. Bug 576: No format specifiers for several types. Rejected https://austingroupbugs.net/view.php?id=576 Although it appears that this would be a useful feature, the lengthy discussion on this topic in the mailing list did not produce any concensus on a portable solution. Therefore, this bug is rejected. If a method for doing this is implemented (or standardized by the ISO C Standard), please file new bug with the result. Next Steps ---------- The next calls are on: No call Mon 2022-09-05 Thu 2022-09-08 (general bugs) Mon 2022-09-12 (general bugs) Apologies in advance: 2022-09-12 Tom Thompson 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)