Minutes of the 14th December 2017 Teleconference Austin-848 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 15th December 2017 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Geoff Clare, The Open Group Andrew Josey, The Open Group (partial) Andreas Grapentin, University of Potsdam, HPI Joerg Schilling FOKUS Fraunhofer David Clissold, IBM (2nd half) Eric Blake, Red Hat Martin Rehak, Oracle, The Open Group OR Richard Hansen, Google Mark Ziegast, SHware Systems Dev. Co. * General news Andrew and Nick reported that they had been on a call with the ISO secretariat. This was related to the standardization at ISO. Some concerns had been raised at SC22. We agreed that we would revert back to the previous paths for future editions (ISO/IEC), but the latest publication was ISO/IEC/IEEE. Nick and Andrew need to hold a meeting with Keld regarding status. There will be a two week break before we pick up in the New Year. * 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 1064: basename() and dirname(): Specification is not complete enough to allow existing thread-unsafe implementations Accept as Marked http://austingroupbugs.net/bug_view_page.php?bug_id=1064 This item is tagged for issue 8. (All page and line numbers are for the 2016 edition) On page 513 lline 17908,17921 XSH section 2.9.1, remove basename() and dirname() from the list of functions that need not be thread-safe. From the basename() and dirname() pages, remove the following two sentences: The basename() function need not be thread-safe. from P624, L21565, and: The dirname() function need not be thread-safe. from P736, L25075. In basename(), page 624 line 21557-21558, change: the string "/". If the string pointed to by path is exactly "//", it is implementation-defined whether '/' or "//" is returned. to: the string "/", except that if the string pointed to by path is exactly "//", it is implementation-defined whether "/" or "//" is returned. In the basename() article on P624, L21561-21564, change this sentence: The basename() function may modify the string pointed to by path, and may return a pointer to internal storage. The returned pointer might be invalidated or the storage might be overwritten by a subsequent call to basename(). to: The basename() function may modify the string pointed to by path, and may return a pointer into the input string. The returned pointer might be invalidated if the input string is subsequently modified or freed. If path is a null pointer or points to an empty string, or if the string pointed to by path consists entirely of the '/' character, the returned pointer may point to constant data that cannot be modified. On page 624 line 21567 section basename() add a new paragraph to the RETURN VALUE section: The basename() function shall always be successful and no return value is reserved to indicate an error. In APPLICATION USAGE on page 625 line 21598 change: None. to: Note that in some circumstances (in particular, when the returned string is required to be "/" or "."), the returned pointer might point into constant data. Therefore, if the application needs to modify the returned data, it should be copied first. On P736 L25069-25071 change: Trailing '/' characters in the path that are not also leading '/' characters shall not be counted as part of the path. If path does not contain to: Trailing '/' characters in the pathname that are not also leading '/' characters shall not be counted as part of the pathname. If the pathname does not contain In the dirname() article on P736, L25073-25074, change this sentence: The dirname() function may modify the string pointed to by path, and may return a pointer to static storage that may then be overwritten by a subsequent call to dirname(). to: The dirname() function may modify the string pointed to by path, and may return a pointer into the input string. The returned pointer might be invalidated if the input string is subsequently modified or freed. If path does not contain a '/', is a null pointer, or points to an empty string the returned pointer may point to constant data that cannot be modified. On page 736 line 25078 section dirname(), in RETURN VALUE change: The dirname( ) function may modify the string pointed to by path, and may return a pointer to internal storage. The returned pointer might be invalidated or the storage might be overwritten by a subsequent call to dirname( ). The returned pointer might also be invalidated if the calling thread is terminated. to: The dirname() function shall always be successful and no return value is reserved to indicate an error. In dirname() APPLICATION USAGE, P737, L25110-25111 change: Since the meaning of the leading "//" is implementation-defined, dirname("//foo) may return either "//" or '/' (but nothing else). to: Since the meaning of the leading "//" is implementation-defined, dirname("//foo") may return either "//" or "/" (but nothing else). Note that in some circumstances, the returned pointer might point into constant data. Therefore, if the application needs to modify the returned data, it should be copied first. (note two quoting fixes: the closing double quotes character after //foo, and change from single quote marks to double quote marks around the returned single /) Change P625, L21600 AND P737, L25113 basename() and dirname() RATIONALE sections from: None. to: Earlier versions of this standard seemed to allow thread-safe and non-thread-safe implementations of basename() and dirname(), but did not allow implementations to return a NULL pointer and require that errno be set when that happened. The standard now requires thread-safe behavior for both of these functions and clearly states that they are always successful. Bug 1065: Clarification request on invocations Rejected http://austingroupbugs.net/bug_view_page.php?bug_id=1065 Rejected for the reasons stated in bugnote:3361. eblake (manager) 2016-08-25 15:29 The general use of '--help' is unspecified; applications can do whatever they want with it (the two most common behaviors are to reject the second '-' as an unknown short option character, or to display help text, but there is no required behavior). Remember, XBD 12.2 guideline 3 states that an option must have an alphanumeric character after the '-', but '--help' does not fit that bill; and the standard then goes on to state that the guidelines are requirements on standard utilities that do not specify otherwise (and true does not specify otherwise); but also specifically allows for extensions: "On some implementations, the utilities accept usage in violation of these guidelines for backwards-compatibility as well as accepting the required form." GNU's 'true --help' behavior is not specified by the standard, because the mere use of '--help' puts the usage outside the realm of defined behavior. Once you invoke an application with arguments that do not have specified behavior, you are no longer guaranteed a particular exit status. Likewise, you are correct in noting that even 'true garbage' is undefined behavior by the standard for passing an argument where the standard did not document one as permitted, and thus is not portably required to have exit status 0. The whole point of unspecified options is that they are unspecified, and we cannot portably define behavior for them. Bug 1067: missing socket() error for unsupported socket type OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1067 if ((type != SOCK_RAW) && (type != SOCK_DGRAM)) { *errorp = ESOCKTNOSUPPORT; return (NULL); } Action on Geoff to propose wording which allows all three existing behaviours for Issue 8 but with the EPROTOTYPE and EPROTONOSUPPORT errors marked OB with the aim of requiring ESOCKTNOSUPPORT in Issue 9. Bug 1068: Binding to a system-assigned port. OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1068 We started discussions and will continue next time. Next Steps ---------- The next call is on January 4th, 2017 (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#