Minutes of the 17th October 2013 Teleconference Austin-631 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 18th October 2013 Attendees Don Cragun, PASC OR Geoff Clare, The Open Group Eric Blake, Red Hat Andrew Josey, The Open Group Joerg Schilling, Fraunhofer Society Nick Stoughton, USENIX, ISO/IEC OR Mark Ziegast David Clissold, IBM (partial) Richard Hansen, BBN (partial) Martin Řehák, Oracle Apologies Mark Brown * General news Nick confirmed he is ok with the current meeting time slot. Andrew still needs to chase up the status of the replacement OR for The Open Group. * 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. * Current Business Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN http://austingroupbugs.net/view.php?id=375 David Korn had returned some proposed text during the week. Action:Geoff agreed to review the input from David Korn and formulate a proposal. Bug 0000755: reused thread id and mutex ownership Accepted as Marked http://www.austingroupbugs.net/view.php?id=755 An interpretation is required. Interpretation response: The standard clearly states that a mutex is owned by the thread that locks it, and conforming implementations must conform to this. Rationale: If an implementation changes the owner of an existing mutex lock to a new thread at some time after the owning thread terminates, that implementation does not conform to the standard's requirements. The lock's owner is required to be the thread that created the lock; not a thread that happens to have the same thread ID as the thread that locked it, a thread that happens to be using the same slot in the system's thread table as the thread that locked it, or any other attribute of a thread that is not tied to the lifetime of the thread. If a conforming implementation wants to use a resource (such as a thread ID) to determine a lock's owner, it must not reuse that resource until all locks that were held by the terminated thread that was using that resource have been released. Notes to the Editor (not part of this interpretation): None. Bug 0000757: missing to option clause OPEN http://www.austingroupbugs.net/view.php?id=757 The editor(s) should check this wording and correct it as appropriate (Action: Andrew) Bug 0000759: Is "may fail" case adequately specified? Rejected http://austingroupbugs.net/view.php?id=759 Rejected as standard is already correct. When an error is "may fail", it is optional whether an implementation of the function detects the error condition. If the function detects the condition it must return the specified error. If it doesn't detect the condition, it carries on as if the condition hadn't occurred. Bug 0000760: asynchronous list assignment of stdin should depend on job control Accepted http://austingroupbugs.net/view.php?id=760 See also: page 3700 line 126628 An interpretation is required This item is tagged for TC2-2008 Interpretation response: The standard states that interactive shells need not reassign standard input, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: This does not match existing practice. Notes to the Editor (not part of this interpretation): Make the changes suggested in the Desired Action. Bug 0000761: Requirement of error for snprintf with n>INT_MAX may conflict with ISO C Rejected http://www.austingroupbugs.net/view.php?id=761 After a lengthy discussion during the October 17, 2013 conference call, we decided that we agree with the sentiment stated in Note: 0001864. The C standard does not specify the behavior when n > INT_MAX, so the current specified behavior does not conflict with the C standard. Although it is possible that snprintf() could be given a huge buffer and use sizeof(buffer) to set the value of n, we believe that (other than for demonstration purposes) this is unlikely to occur. We do not believe the standard needs to be changed for this corner case. Therefore, this bug is rejected. Next Steps ---------- The next call is on October 31, 2013 (a Thursday) 8am PDT = 3pm GMT (4pm CET) Calls are anchored on US time. 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 We are now using an Etherpad for note taking - the URL is given at the start of the meeting in IRC