Minutes of the 29th August 2013 Teleconference Austin-624 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 31st August 2013 Attendees Don Cragun, PASC OR Geoff Clare, The Open Group Eric Blake, Red Hat Andrew Josey, The Open Group Mark Brown Nick Stoughton, USENIX, ISO/IEC OR Joerg Schilling, Fraunhofer Society Richard Hansen, BBN Apologies David Clissold, IBM Mark Ziegast * General news No general news. * 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 0000720: Can pthread_rwlock_wrlock be called recursively by the same thread? Accepted as Marked http://austingroupbugs.net/view.php?id=720 An interpretation is required. This item is tagged for TC2-2008 Interpretation response: The standard clearly states that reader-writer locks held for reading are recursive and that reader-writer locks held for writing are not recursive, and conforming implementations must conform to this. Rationale: It is clear from the description of pthread_rwlock_[try]rdlock() and pthread_rwlock_unlock() that read locks are recursive. It is clear from the description of pthread_rwlock_trywrlock() and pthread_rwlock_unlock() that write locks are not recursive. The intention is that pthread_rwlock_wrlock() either deadlocks or returns EDEADLK if the caller already holds a write lock, but this is written as two separate "may" clauses (one in the DESCRIPTION and one in the ERRORS section), which creates a loophole that allows pthread_rwlock_wrlock() to succeed (as a no-op). However, this behavior would be of no use to applications. In particular, if an application tried to make matching pthread_rwlock_unlock() calls for two successful pthread_rwlock_wrlock() calls, the first unlock call would set the state to unlocked and the second unlock call would result in undefined behavior. Notes to the Editor (not part of this interpretation): Change: The calling thread acquires the write lock if no other thread (reader or writer) holds the read-write lock rwlock. Otherwise, the thread shall block until it can acquire the lock. The calling thread may deadlock if at the time the call is made it holds the read-write lock (whether a read or write lock). to: The calling thread shall acquire the write lock if no thread (reader or writer) holds the read-write lock rwlock. Otherwise, if another thread holds the read-write lock rwlock, the calling thread shall block until it can acquire the lock. If a deadlock condition occurs or the calling thread already owns the read-write lock for writing or reading, the call shall either deadlock or return EDEADLK. *Bug 0000742 Generated links are faulty generated OPEN http://austingroupbugs.net/view.php?id=742 Mark Brown has taken an action item to update the documentation for the Mantis system Bug 0000736: 5 shift/reduce conflicts in Shell Grammar Rules Accepted as Marked http://austingroupbugs.net/view.php?id=736 An interpretation is required. This item is tagged for TC2-2008 Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The following changes make the grammar and text reflect existing practice. Notes to the Editor (not part of this interpretation): On page 2350, lines 74801-74808, change %start complete_command %% complete_command : list separator | list ; to: %start program %% program : linebreak complete_commands linebreak | linebreak ; complete_commands: complete_commands newline_list complete_command | complete_command ; complete_command : list separator_op | list ; Cross-volume change to XRAT... At page 3700 line 126612 section C.2.10 delete: The start symbol of the grammar (complete_command) represents either input from the command line or a shell script. It is repeatedly applied by the interpreter to its input and represents a single "chunk" of that input as seen by the interpreter. Bug 0000737: two of Shell Grammar Rules unnecessary Accept http://austingroupbugs.net/view.php?id=737 This item is tagged for TC2-2008 Next Steps ---------- We will pick up on Bug 738 next time. The next call is on September 5, 2013 (a Thursday) 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