Minutes of the 4th January 2018 Teleconference Austin-849 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 6th January 2018 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Andrew Josey, The Open Group David Clissold, IBM Andreas Grapentin, University of Potsdam, HPI Joerg Schilling FOKUS Fraunhofer Eric Blake, Red Hat Richard Hansen, Google Mark Ziegast, SHware Systems Dev. Co. Apologies Martin Rehak, Oracle, The Open Group OR * General news We discussed the front matter for the POSIX.1-2017 standard. We will still note that The Open Group approved the standard in June 2016. Andrew is targeting to submit the standard to IEEE by January 12th, so it can be published at the end of January. Andrew and Nick are hoping to meet with Keld soon, to discuss the SC22 concerns regarding the approvals process, which we believe we have now resolved with ISO, ANSI and IEEE. * Outstanding actions ( Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 28 Jan 2016) Bug 0000249: Add standard support for $'...' in shell Reopened http://austingroupbugs.net/bug_view_page.php?bug_id=249 We will return to bug 249 on a future call. Bug 0000953: Alias expansion is under-specified Was Accepted as Marked http://austingroupbugs.net/view.php?id=953 Richard has an action to propose new wording to discuss in a future telecon. * Current Business Bug 1067: missing socket() error for unsupported socket type Accept as Marked http://austingroupbugs.net/bug_view_page.php?bug_id=1067 This item is tagged for Issue 8 In the Dec 14 teleconference it was decided to allow all three behaviours in Issue 8 but with OB shading and future directions as a warning that we intend to require ESOCKTNOSUPPORT in Issue 9. Proposed changes: (All page and line numbers are for the 2016 edition.) On page 236 line 7959 section XBD , add: [ESOCKTNOSUPPORT] Socket type not supported. On page 487 line 16832 section XSH 2.3 Error Numbers, add: [ESOCKTNOSUPPORT] Socket type not supported. The socket type is not supported by the address family, or the socket type is not supported by the implementation. On page 2005 line 64494-64497 section socket(), change: [EPROTONOSUPPORT] The protocol is not supported by the address family, or the protocol is not supported by the implementation. [EPROTOTYPE] The socket type is not supported by the protocol. to: [EPROTONOSUPPORT] The value of protocol is non-zero and either the protocol is not supported by the address family or the protocol is not supported by the implementation. [EPROTOTYPE] The value of protocol is non-zero and the socket type is not supported by the protocol. [ESOCKTNOSUPPORT] [OB]or [EPROTONOSUPPORT] or [EPROTOTYPE][/OB] The socket type is not supported by the address family, or the socket type is not supported by the implementation. On page 2005 line 64510-64513 section socket() change: RATIONALE None. FUTURE DIRECTIONS None. to: RATIONALE Historically the standard did not specify the errno value to be used when the socket type is not supported, and there were differences between implementations. Some reused the existing standard [EPROTONOSUPPORT] or [EPROTOTYPE] values while others set errno to a (then) non-standard value of [ESOCKTNOSUPPORT]. All three values are permitted in this version of the standard, but the use of [EPROTONOSUPPORT] or [EPROTOTYPE] is considered to be misleading when no protocol is specified (that is, the value of protocol is zero) and consequently those alternatives have been marked obsolescent. If protocol is non-zero, since there is no precedence between error conditions, all three values will still be permitted even after the obsolescent alternatives for the [ESOCKTNOSUPPORT] condition have been removed. FUTURE DIRECTIONS A future version of this standard may disallow setting errno to [EPROTONOSUPPORT] or [EPROTOTYPE] when the socket type is not supported and protocol is zero. Bug 1068: Binding to a system-assigned port. OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1068 Action item: Andrew to ask Martin if there is anyone at Oracle who is active at IETF, who could forward the issue and sponsor it at IETF Bug 1069: with a process group ID equal to (/*are you sure?*/pid_t)id Rejected http://austingroupbugs.net/bug_view_page.php?bug_id=1069 We do not want to make any special markings just on this page for one or two defined terms. We have, however, suggested to the editor that it would be nice if all uses of terms defined in the standard could be presented as links that, if clicked, would take you to the definition of that term in the XBD volume of the standard. Since this is a huge amount of work for the editor, we do not know if this suggestion will be implemented any time soon, or at all. Bug 1070: Collation issues in XCU (changes for Issue 8) Accepted http://austingroupbugs.net/bug_view_page.php?bug_id=1070 This item is tagged for Issue8. Bug 1071: Name space reservation should move to XBD Accepted http://austingroupbugs.net/bug_view_page.php?bug_id=1071 This item is tagged for Issue8 Also see: http://austingroupbugs.net/bug_view_page.php?bug_id=901 http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9907 Approved with note: Although we are reserving these namespaces for use by the standards, we realize that there is some existing practice using some names in these namespaces. Since these namespace reservations won't be formal until Issue 8 is adopted and we plan to start using some names in these namespaces in Issue 8, we will attempt not to break existing code while producing Issue 8 of the standard. (We try to avoid name collisions even when there are namespace reservations anyway, but there is always a chance that we will pick a name and not know that the name has been used for some other purpose.) Next Steps ---------- The next call is on January 11th, 2018 (a Thursday) Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756#