Minutes of the 20 March 2014 Teleconference Austin-649 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 21 March 2014 Attendees: Mark Ziegast, SHware Systems Eric Blake, Red Hat Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Don Cragun, IEEE PASC OR Geoff Clare, The Open Group David Clissold, IBM Richard Hansen, BBN Joerg Schilling FOKUS Fraunhofer Mark Brown, Canonical Apologies: Martin Rehak, Oracle, The Open Group OR David Wheeler, IDA * General news On the issues forwarded (794/800) to the Base Working Group, Andrew is progressing this towards a conclusion with the Base WG. On TC2 development, Andrew reported he was progressing and was on bug 158 out of 173 in his current queue. Andrew reported he had an acknowledgement back from the IEEE staff liaison on the matter of access to historical draft standards and is awating the response. * Outstanding actions +Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 Don has an action to produce a proposal. +Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN http://austingroupbugs.net/view.php?id=561 Eric has an action to update the proposal. +Bug 0000573: Please add '+' to the portable filename character set OPEN http://austingroupbugs.net/view.php?id=573 Joerg has an action to prepare a proposed change. +Bug 0000592: consistent use of struct timespec OPEN http://austingroupbugs.net/view.php?id=592 Jim had provided additional information in bugnote 1627. This was discussed and Jim took an action to provide further information. +Bug 0000598: OH shading and new interfaces OPEN http://austingroupbugs.net/view.php?id=598 Eric has an action to propose a new solution with self-contained headers. +Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 Action on Joerg to look at this. +Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 We noted that feedback has settled down on the mailing list, and will discuss next session. +Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN http://austingroupbugs.net/view.php?id=657 Eric has an action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. +Bug 0000658: Undefined/unspecified behavior clauses in description of open have race conditions OPEN http://austingroupbugs.net/view.php?id=658 It was noted that there is some overlap with changes in TC1. Eric took an action to update the proposal to resolve the overlaps appropriately. +Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN http://austingroupbugs.net/view.php?id=615 We now have reports on AIX and Apple. Jim to report back on whether pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask HP whether pthread_cancelstate() is async-signal-safe on HP-UX. +Bug 622 left open pending resolution of 615. http://austingroupbugs.net/view.php?id=622 +Bug 0000672: Necessary step(s) to synchronize filename operations on disk OPEN http://austingroupbugs.net/view.php?id=672 Geoff has a new proposed resolution in note 1618. Decided to solicit input from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris. Jim has completed his action (see bugnote 1691). Andrew should chase HP and Apple for input. +Bug 0000663: Specification of str[n]casecmp is ambiguous reopened http://austingroupbugs.net/view.php?id=663 Action on David to follow up with the IBM developers about the EBCDIC collation sequence. Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification http://www.austingroupbugs.net/view.php?id=696 Don has an action to propose a resolution. Bug 0000721: Internal storage vs static storage OPEN http://austingroupbugs.net/view.php?id=721 This item is still open. Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN http://austingroupbugs.net/view.php?id=375 This is still left open due to discussions pending on the reflector. Bug 0000789: Add set -o pipefail OPEN http://austingroupbugs.net/view.php?id=789 Bug 0000794: Add a function series for formatted error messages OPEN http://austingroupbugs.net/view.php?id=794 Martin has completed his action to forward to The Open Group Base Working group to see if they would be willing to sponsor this proposal for new interfaces. Bug #0000800: Add support for the recursive printf() format %r OPEN http://austingroupbugs.net/view.php?id=800 Joerg has an action to write a new proposal. Martin has also forwarded this to The Open Group Base Working group for their consideration. * Current Business Eric has an action on fnmatch() with FNM_PATHNAME whichis still open. Andrew completed his action to define a new tag for errata items (the tag is errata). Typical items that are errata are where a change in the approved TC1 was not applied to the 2013 edition. These should be corrected at the first opportunity by the editors. AI: Andrew to check the interpretations queue. Bug #819: permit prompting only once when encountering a directory with 'rm -ir' Accepted as Marked http://www.austingroupbugs.net/view.php?id=819 This item is tagged for TC2-2008 An interpretation is required. Interpretation response: The standard states the requirements for prompting by rm, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The standard does not allow an optimization that is currently in use. Notes to the Editor (not part of this interpretation): Insert the following text at the start of step 2b (page 3161 line 105682): If file is an empty directory, rm may skip to step 2d. Bug #811: precondition for mutex destruction unclear; example contradicts normative text OPEN http://www.austingroupbugs.net/view.php?id=811 Input from David Butenhof: This is an incredibly bad code example. Any thread "done" with the dynamic object using this model would start out by locking the mutex in order to determine whether the object has been destroyed, courting disaster and essentially defeating the purpose one might expect for an example in this context. The point was to demonstrate that the mutex might become invalid or go away, making the effect of pthread_mutex_lock() undefined -- and yet this "protection" sequence starts out by blindly locking the mutex. POSIX.4 Rationale was defined more loosely than the current UNIX standardization guidelines. It was, at best, "informative", and often simply "conversational"; it was not considered a part of the standard and could not place constraints or requirements on either implementation or application use. In any case where POSIX.4 normative text appears to contradict rationale, start by assuming that the rationale is either flat out wrong or (probably more kindly than it deserves) just "not properly maintained as the normative text evolved". In this particular case, I believe the example was probably intended as a rough "back of the napkin sketch" to suggest an approach to a valid solution (though I don't think it actually does so); and in the context of POSIX.4 rationale it wasn't considered worth the effort to make it robust or complete; and probably nobody ever read it again after that draft was finished. But the normative text, the part POSIX.4 cared about and fought over, is clear: It shall be safe to destroy an initialized mutex that is unlocked. Attempting to destroy a locked mutex or a mutex that is referenced (for example, while being used in a pthread_cond_timedwait( ) or pthread_cond_wait( )) by another thread results in undefined behavior. This requirement explicitly (though more subtly than necessary) precludes the implementation from any reference to the user-visible storage associated with a mutex past the completion of the internal atomic unlock operation. (Because any number of threads may still be within that "epilog" code when some arbitrary unlocking thread returns to application code.) However, it is the application's responsibility to ensure that no threads subsequently provoke any additional references to the mutex -- such as a lock call (like the one in the example), an unlock call, or a condition wait unblock; these are all explicitly undefined operations. The example is bad practice at best, and the accompanying explanation is not of much use. It might be sufficient to more directly state that allowing mutex destruction immediately following any return from unlock requires that implementations SHALL refrain from any reference to the user-visible mutex storage following the internal atomic unlock operation. (In other words, 'yes, we really mean that it's safe for "you" to destroy it without worrying what "we" might be doing'.) And, by the way, note that I carefully said "reference to the *user-visible* mutex storage" because if a pthread_mutex_t is implemented as a pointer or handle to storage managed by the kernel or pthread library, then that indirect storage need not be subject to this rule; and it's one reason that our original implementation worked that way. (Another was that "some of us" really didn't trust users to manage any storage we needed; and though I often pushed for more efficient and simpler models, it's hard to argue they were wrong!) If there's an example, it should be a useful and informative example that doesn't solicit undefined behavior. In other words, it should be completely different from the example that's there. Removing it entirely seems like a perfectly good alternative. AI:Andrew to ask Dave if he could supply a new example (action completed) We have left this item open pending further input from Dave. Bug #821: wcscasecmp page says LC_CTIME when it means LC_CTYPE Accepted http://www.austingroupbugs.net/view.php?id=821 This item is tagged errata Bug #822: missing symlink [ENOENT] or [ENOTDIR] error Accepted as Marked http://www.austingroupbugs.net/view.php?id=822 This item is tagged for TC2-2008 At page 622 line 21271 section bind change: If the pathname names an existing file, an [ENOENT] error shall not occur. to: If the pathname without the trailing characters would name an existing file, an [ENOENT] error shall not occur. At page 884 line 29607 section fopen and page 932 line 31432 section freopen change: If pathname names an existing file, an [ENOENT] error shall not occur. to: If pathname without the trailing characters would name an existing file, an [ENOENT] error shall not occur. At page 1229 line 40836 section link add after the [ENOENT] error: [ENOENT] or [ENOTDIR] The path1 argument names an existing non-directory file, and the path2 argument contains at least one non- character and ends with one or more trailing characters. If path2 without the trailing characters would name an existing file, an [ENOENT] error shall not occur. At page 1308 line 43264 section mkfifo, page 1312 line 43423 section mknod and page 1394 line 46111 section open change: If path names an existing file, an [ENOENT] error shall not occur. to: If path without the trailing characters would name an existing file, an [ENOENT] error shall not occur. At page 2074 line 66175 section symlink add after the [ENOENT] error: [ENOENT] or [ENOTDIR] The path2 argument contains at least one non- character and ends with one or more trailing characters. If path2 without the trailing characters would name an existing file, an [ENOENT] error shall not occur. Bug #823: TC1 fscanf RETURN VALUE change needs to be done to fwscanf Accepted http://www.austingroupbugs.net/view.php?id=823 This item is tagged for TC2-2008 Bug #825: Pathname resolution and empty symbolic links Accepted as Marked http://www.austingroupbugs.net/view.php?id=825 This item is tagged for TC2-2008 At page 112 line 3050 section 4.12, after applying 0000649 change: In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. If the contents of the symbolic link is the empty string, then either errno shall be set to [ENOENT] and an error indication shall be returned, or the pathname of the directory containing the symbolic link shall be used in place of the contents of the symbolic link. If the combined length exceeds {PATH_MAX}, and the implementation considers this to be an error, errno shall be set to [ENAMETOOLONG] and an error indication shall be returned. to: In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link, except that if the contents of the symbolic link is the empty string, then either pathname resolution shall fail with functions reporting an [ENOENT] error and utilities writing an equivalent diagnostic message, or the pathname of the directory containing the symbolic link shall be used in place of the contents of the symbolic link. In the cases where prefixing occurs, if the combined length exceeds {PATH_MAX}, and the implementation considers this to be an error, pathname resolution shall fail with functions reporting an [ENAMETOOLONG] error and utilities writing an equivalent diagnostic message. At page 112 line 3056 section 4.12 change: If the system detects a loop in the pathname resolution process, it shall set errno to [ELOOP] and return an error indication. to: If the system detects a loop in the pathname resolution process, pathname resolution shall fail with functions reporting an [ELOOP] error and utilities writing an equivalent diagnostic message. Bug #826: setlocale() should not be required to be thread-safe Accepted http://www.austingroupbugs.net/view.php?id=826 This item is tagged for TC2-2008 Bug #828: Additional M_ constants for math.h Accepted as Marked http://www.austingroupbugs.net/view.php?id=828 This item is tagged for Issue 8 Change lines 9595 - 9609 to read: The header shall define the following symbolic constants. Where the constant name ends in "l" (lower case ell), the values shall have type long double; otherwise the values shall have type double. The values shall be accurate to the precision of their type. If the implementation supports FLT_EVAL_METHOD values other than 0 or 1, the values shall either include an explicit cast for that type, or be expressed as hexadecimal floating constants. Double Long Double Value ---------- ------------ ---------------- M_E M_El Value of e M_LOG2E M_LOG2El Value of log2 e M_LOG10E M_LOG10El Value of log10 e ... M_SQRT1_2 M_SQRT1_2l Value of 1/sqrt2 Remove the following application usage addition from 0000801 (p 295, line 9860): Note that if FLT_EVAL_METHOD is neither 0 nor 1, then some constants might not compare equal as expected, for example (double)M_PI == M_PI can fail. Add Rationale text on page 295 after line 9867: The requirement for an explicit cast or representation via hexadecimal floating constants is to guarantee that even when FLT_EVAL_METHOD is neither 0 nor 1, the expression (double)M_PI == M_PI will always hold true. Earlier versions of this standard did not make this requirement, because they lacked the "l" (lower case ell) versions of the constants and were allowed to provide M_PI with long double precision depending on FLT_EVAL_METHOD. Next Steps ---------- The next call is on April 3, 2014 (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: http://posix@posix.rhansen.org:9001/p/201x-mm-dd password=2115756#