Minutes of the 27 Jan 2011 Teleconference Austin-511 Page 1 of 1 Submitted by Andrew Josey, The Open Group. January 28 , 2010 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Mark Brown, IBM, TOG OR Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Eric Blake, Red Hat *Old Business carried forward: We discussed the draft PAR that had been circulated to the core team. Some changes were identified. It was agreed that we need to submit to the next PASC SEC meeting, and so need to ensure it is raised as an agenda item. Andrew noted that we also need to complete the PASC PMC criteria. We will need to estimate a schedule for draft development. Andrew will contact Michael Kipness for guidance on the cutoff dates for PAR approval to assist with the planning. Action: Andrew email the PASC SEC to add the PAR to the agenda of their next meeting (completed) Action: Andrew to email Michael Kipness to find out the PAR approval schedule (completed) * New Business * We picked up on regular Bug processing Open Interp -- 347 Bug 0000347: ASYNCHRONOUS EVENTS on sh page should not be "Default" Accepted as marked http://austingroupbugs.net/view.php?id=347 Geoff agreed to take an action to revise the response and then we will restart the 30 day review clock. (This was completed after the meeting and the comment period for the interpretation ends on February 27th) Bug 0000354: limit on the number of owned robust mutexes Accepted as marked. http://austingroupbugs.net/view.php?id=354 Mark had completed his action with the following proposal: For pthread_cond_timedwait() and pthread_cond_wait(), insert the following text as a new line, after line 51058 on page 1587: [EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded. For pthread_mutex_setprioceiling(), insert the following text as a new line, after line 52629 on page 1634: [EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded. For pthread_mutex_lock(), insert the following text as a new line, after line 52746 on page 1639: [EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded. For pthread_mutex_timedlock(), insert the following text as a new line, after line 52899 on page 1644: [EAGAIN] The mutex is a robust mutex and the system resources available for robust mutexes owned would be exceeded. (0000656) This was tagged for Issue 8 and should go down the interpretations track. Interpretation response: The standard does not speak to this issue, and as such 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): Make the changes noted in the proposal. Bug 0000359: Incorrect specification of error return for a negative value of unsigned msgsz argument Accepted http://austingroupbugs.net/view.php?id=359 This was tagged for TC1-2008 Bug 0000360: ctermid should be optional in Accepted as Marked http://austingroupbugs.net/view.php?id=360 This item is tagged for TC1-2008 and also sent down the interpretations track. Interpretation response The standard states that shall include a function prototype for ctermid(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Some implementations have had a declaration for ctermid() and this should still be allowed in Issue 7. Having ctermid() and pthread_atfork() prototypes in , however, are namespace pollution issues that should be corrected in the next revision. Notes to the Editor (not part of this interpretation): Delete line 15048 (ctermid declaration in XBD ). At line 15124 (), add a sentence: Implementations may also include the ctermid( ) prototype as defined in . Tag the entire paragraph starting on line 15124 including the above new sentence with the OB margin marking. Bug 0000361: Typo in Issue 7 Change History Accepted http://austingroupbugs.net/view.php?id=361 This item is tagged for TC1-2008 Bug 0000362: Unneeded pointer page Rejected http://austingroupbugs.net/view.php?id=362 open_memstream() appears on page 1388, between open() and openat(). Therefore the pointer page is needed. Bug 0000363: shmget() redundant condition for error [EINVAL] Accepted http://austingroupbugs.net/view.php?id=363 This item is tagged for TC1-2008. Bug 0000364: trigraph mapping is wrong Accepted http://austingroupbugs.net/view.php?id=364 This item is tagged for TC1-2008. Bug 0000366: ftok() with paths on the same filesystem Accepted as marked http://austingroupbugs.net/view.php?id=366 This item is tagged for TC1-2008. An interpretation is needed. Interpretation response The standard states that the key shall be unique, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: See notes above. No current implementation is known to provide unique keys. Notes to the Editor (not part of this interpretation): For TC1, proposed change is: On line 32809 change "and return different key values when called with different id ..." to "and should return different key values when called with different id ..." Add to Application Usage: No guarantee can be given that the resulting key value is unique. In Examples, on line 32119 and 32129 delete the word "unique". In Future Directions change "None" to "Future versions of this standard may add new interfaces to provide guaranteed unique keys." Next Steps ---------- The next call will be on February 3rd 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