Minutes of the 6th April 2023 Teleconference Austin-1305 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 7th 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 We decided we would switch 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 38% (7 ballots out of 18 received). * 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 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 Bug 1641: sockaddr_storage is not alias safe Accepted as Marked https://austingroupbugs.net/view.php?id=1641 An interpretation is required. 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 these casts do not cause the compiler to produce diagnostics about aliasing issues in accessing the sa_family_t member of these structures when compiling conforming application (xref to XBD section 2.2) source files. 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 700: Clarify strtoul's behaviour on strings representing negative numbers Accepted as Marked https://austingroupbugs.net/view.php?id=700 This item is tagged for TC3-2008. On 2018 edition page 2081 line 66795 section strtol(), and page 2277 line 72497 section wcstol(), change: the value resulting from the conversion shall be negated. to: the resulting value shall be the negative of the converted value. On 2018 edition page 2086 line 66909 section strtoul(), and page 2284 line 72661 section wcstoul(), change: the value resulting from the conversion shall be negated. to: the resulting value shall be the negative of the converted value; this action shall be performed in the return type. We will discuss where to start on the next call, it was undecided whether to start at 1650 next or look to the D3 bugs received. Next Steps ---------- The next calls are on: Mon 2023-04-10 NO MEETING (Easter) then no Monday meetings until June Thu 2023-04-13 (general bugs) Thu 2023-04-20 (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)