Minutes of the 6th October 2011 Teleconference Austin-539 Page 1 of 1 Submitted by Andrew Josey, The Open Group. October 8 , 2011 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Mark Brown, IBM, TOG OR Jim Pugsley, Oracle Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Eric Blake, Red Hat The TC1-2008 Draft 4 document is progressing, and a release candidate has been sent to IEEE for a final Mandatory Editorial Coordination review. Cathy has continued merging the changes into the BaseI7 tree and that is still a work in progress. Andrew noted that the POSIX C++ binding project was able to timeout. It was agreed that lack of forward progress meant that this will likely to be withdrawn. The issue has been forward to the PASC SEC and they need to make a recommendation. * New Business We discussed the mail item on the dd utility and unicode. (mail seq 16542) We concluded that we want to change the wording to limit the lcase and ucase translations to single byte locales as they cannot work on multibyte locales. We will need to have an aardvark filed. We were not happy with limiting the conversion to ASCII. There will need to be some discussion about conv=ascii, ibm and ebcdic overriding the current locale for case conversions. Bug 0000495 It is not clear if N calls to pthread_cond_signal() will wake at least N thread Reject http://austingroupbugs.net/view.php?id=495 The teleconference on 6th October agreed with Dave Butenhof's response in mail item 16529: N successive calls to pthread_cond_signal() will wake N threads IF there is at least one thread blocked on the condition variable at each call. Whether those are N unique threads or some manage to slip around and get back in line is an issue beyond the scope of the standard. Note in particular that "N calls to pthread_cond_signal() will NOT necessarily wake at least N threads", because a call to pthread_cond_signal() when no thread is waiting will silently do nothing at all. If you call pthread_cond_signal() while a single thread was waiting, it's unblocked. If you then call pthread_cond_signal() 100 times more in succession while no thread is waiting, nothing happens. If another thread then blocks on the condition variable, it will continue to wait until a subsequent call to pthread_cond_signal() regardless of the 100 preceding calls that did nothing. "Wait morphing", moving the unblocked thread directly to the wait queue of the associated mutex (if locked), can be a useful optimization, but is deliberately not required by the standard. And of course you definitely don't really want the standard to say "the unblocked thread will move to waiting for the mutex before pthread_cond_signal() has returned", because a thread that's unblocked while the associated mutex is unlocked should be able to acquire the mutex without blocking. Threads awakened, singly or via broadcast, from a condition wait become eligible to contend for the associated mutex along with any other threads that might try; subject to multiprocessor scheduling, priorities, page faults, and any and all other conditions that may impact the execution timing of individual threads. Bug 0000496: 2.3 ENOSYS description inconsistent with encrypt() Accepted as Marked http://austingroupbugs.net/view.php?id=496 This item is tagged for TC2-2008 An interpretation is required. 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: None. Notes to the Editor (not part of this interpretation): Change: Function not implemented. An attempt was made to use a function that is not available in this implementation. to: Functionality not supported. An attempt was made to use optional functionality that is not supported in this implementation. At XBD page 236 line 7737 change: [ENOSYS] Function not supported. to: [ENOSYS] Functionality not supported. At XRAT page 3504 line 117934 change: The return of [ENOSYS] is to be taken to indicate that the function of the interface is not supported at all; the function will always fail with this error code. to: In some earlier versions of this standard, the difference between [ENOTSUP] and [ENOSYS] was that [ENOSYS] indicated that the function was not supported at all. This is no longer the case as [ENOSYS] can also be used to indicate non-support of optional functionality for a function that has some required functionality. (See XSH encrypt().) Bug 0000497: catopen has undefined semantics with regards to NLSPATH Accepted as Marked http://austingroupbugs.net/view.php?id=497 This item is tagged for TC2-2008 Add a new paragraph to APPLICATION USAGE (after line 21734): To be sure that messages produced by an application running with "appropriate privileges" cannot be used by a attacker setting an unexpected value for NLSPATH in the environment to confuse a system administrator, such applications should use pathnames containing a '/' to get defined behavior when using catopen() to open a message catalog. Also at line 21685 change "...on page 173). If NLSPATH exists in the environment ..." to "on page 173); if NLSPATH exists in the environment..." Bug 0000498: During process termination, open file descriptors should be closed as if by appropriate calls to close() OPEN http://austingroupbugs.net/view.php?id=498 This item was discussed but no conclusion reached as yet. Next Steps ---------- The next call is on October 20th at 08:00 Pacific and will continue processing defect reports. This call will be for the regular 90 minutes. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic