Minutes of the 13th April 2023 Teleconference Austin-1306 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 14th April 2023 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Andrew Josey, The Open Group Mark Ziegast, SHware Systems Dev. Eric Blake, Red Hat, The Open Group OR Apologies Eric Ackermann, HPI, University of Potsdam * General news A reminder that we have switched to meeting once per week (on Thursdays) while the current ballot is in progress, that is until June. On the IEEE ballot status we had 4 comments received to date (2 editorial, 2 technical), with a return rate of 50% (9 ballots out of 18 received). Andrew reported on a meeting held with IEEE about the future of the PASC committee. IEEE plans to close the committee and move the POSIX work group to the Microprocessor Committee. This is to reduce administration at the IEEE. Operations should not be impacted. This is expected to occur around September and we will find out more about how the change will occur and meet with the committee members. * Carried Forward This section trimmed -- see Austin/1264 Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer size OPEN https://austingroupbugs.net/view.php?id=1406 Actions carried forward: ACTION: Andrew to contact Rich Felker (dalias) and Alan Coopersmith (Solaris) for feedback. Completed ACTION: Eric B to contact glibc folks. Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 We will need a sponsor; it is not suitable for inclusion in Issue 8. ACTION: Eric to ask The Open Group to sponsor adding the mktemp utility (for Issue 9). Bug 1291: Add method to obtain pthread attributes OPEN https://austingroupbugs.net/view.php?id=1291 Needs additional details and sponsor for Issue 9 Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 (brought forward) Don has an action to produce a proposal. Bug 1622: Standardize getpeereid function OPEN https://austingroupbugs.net/view.php?id=1622 Action: Eric B to ask The Open Group if they are willing to sponsor this function for Issue 9. * Current Business Bug 1641: sockaddr_storage is not alias safe Accepted as Marked https://austingroupbugs.net/view.php?id=1641 The interpretation was revised. Andrew took an action to restart the interpretation (completed after meeting). Interpretation response: The standard clearly states that when a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure maps onto the sa_family field of the sockaddr structure and when a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field maps onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family, and conforming implementations must conform to this. Rationale: In stating these field mapping requirements when a cast operator is applied to the various socket address structures, the standard defines the behavior in circumstances where the behavior is undefined in the ISO C standard. The onus is on implementations to ensure that these mappings are as described in the standard, making use of implementation-specific extensions if necessary, even though this is not stated explicitly. Notes to the Editor (not part of this interpretation): On page 386 line 13115 section DESCRIPTION, change: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. to: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, or vice versa, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, or vice versa, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. When a pointer to a sockaddr structure is cast as a pointer to a protocol-specific address structure, or vice versa, the sa_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. Additionally, the structures shall be defined in such a way that the compiler treats an access to the stored value of the sa_family_t member of any of these structures, via an lvalue expression whose type involves any other one of these structures, as permissible, despite the more restrictive expression rules on stored value access as stated in the ISO C standard. On page 390 line 13260 section APPLICATION USAGE, append a sentence: Note that this example only deals with size and alignment; see RATIONALE for additional issues related to these structures. On page 390 line 13291 section , change RATIONALE from "None" to: Note that defining the sockaddr_storage and sockaddr structures using only mechanisms defined in early editions of the ISO C standard may produce aliasing diagnostics when applications use casting between pointers to the various socket address structures. Because of the large body of existing code utilizing sockets in a way that could trigger undefined behavior due to strict aliasing rules, this standard mandates that these structures can alias each other for accessing the sa_family_t member of the structures, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension, to comply with the requirements of this standard. Bug 1630: Alias names https://austingroupbugs.net/view.php?id=1630 OPEN (brought forward) There is a proposal in the etherpad for feedback. See https://posix.rhansen.org/p/2023-02-27 We discussed this item and will continue next time. Next Steps ---------- The next calls are on: Thu 2023-04-20 (general bugs) Thu 2023-04-27 (general bugs) tentative 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)