Minutes of the 15 January 2009 Teleconference Austin-446 Page 1 of 1 Submitted by Andrew Josey, The Open Group. January 16 , 2009 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Geoff Clare, The Open Group Larry Dwyer, HP Ulrich Drepper, Red Hat Tom Honermann, Oracle Roger Faulkner, Sun * Aardvark We picked up on the aardvark reports, which are located at http://www.opengroup.org/austin/aardvark/latest/ * 2008 aardvarks Andrew updated the defect reports during the call. XSHbug3 ERN 15 We rediscussed the item. It was agreed that a future revision should mandate posix_spawn() and add that to the list of async-signal-safe functions. The decision to make fork() async-signal unsafe in a future revision from last week still stands. XSHbug3 ERN 19 Section 2.9.3 EOWNERDEAD Accept @ page 508 line 17536-17542 section 2.9.3 objection [gwc 2.9.3 EOWNERDEAD] Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The second paragraph of 2.9.3 states: A thread shall become the owner of a mutex, m, when one of the following occurs: * It returns successfully from pthread_mutex_lock( ) with m as the mutex argument. * It returns successfully from pthread_mutex_trylock( ) with m as the mutex argument. * It returns successfully from pthread_mutex_timedlock( ) with m as the mutex argument. * It returns (successfully or not) from pthread_cond_wait() with m as the mutex argument (except as explicitly indicated otherwise for certain errors). * It returns (successfully or not) from pthread_cond_timedwait() with m as the mutex argument (except as explicitly indicated otherwise for certain errors). There are two problems with this: 1. The first three bullet items do not account for the EOWNERDEAD error, for the named functions and the pthread_mutex_setprioceiling() function, where the mutex is acquired even though the call is not successful. 2. The last two bullet items talk about explicit exceptions for errors which do not acquire the mutex, but there are no such exceptions stated on the pthread_cond_timedwait() page - instead it has a statement for EOWNERDEAD that the mutex is acquired, and a statement in the DESCRIPTION about pthread_cond_timedwait() timeouts: "When such timeouts occur, pthread_cond_timedwait() shall nonetheless release and re-acquire the mutex referenced by mutex." Action: On lines 17536-17538 (first 3 bullet items), change: It returns successfully from [...] with m as the mutex argument. to It calls [...] with m as the mutex argument and the call returns zero or EOWNERDEAD. After line 17538 (3rd bullet item) add a new bullet item: * It calls pthread_mutex_setprioceiling() with m as the mutex argument and the call returns EOWNERDEAD. Replace lines 17539-17542 (last 2 bullet items) with: * It calls pthread_cond_wait() with m as the mutex argument and the call returns zero or certain error numbers (see [xref to pthread_cond_timedwait() page]). * It calls pthread_cond_timedwait() with m as the mutex argument and the call returns zero or certain error numbers (see [xref to pthread_cond_timedwait() page]). XBDbug3 ERN 3 signal.h Accept @ page 330 line 11032 section signal.h editorial [gwc SIGPROF XSR] Problem: Edition of Specification (Year): 2008 Defect code : 1. Error In the September 2006 plenary meeting, the decision was made to make SIGPROF obsolescent in the revision. The minutes (Austin/317) state: signal.h: SIGPOLL should be OB as well as XSR. SIGPROF: should be OB (but SIGSYS SIGTRAP just XSI). However, this change was not implemented correctly in POSIX.1-2008, where the shading for SIGPROF changed from XSI to OB XSR, instead of to OB XSI. Action: Change the shading on SIGPROF from OB XSR to OB XSI. XCUbug3 ERN 4 XCU mv Accept (**note that we would encourage all to check their implementations as to whether this would cause breakage) @ page 2955 line 97288 section mv objection [gwc mv AI-016] Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The following text was added to the end of the first paragraph on the mv page in the 2008 revision, as a result of interpretation AI-016: "In this case, if target_file ends with a trailing character, mv shall treat this as an error and no source_file operands will be processed." Here, "in this case" is a reference to "the final operand does not name an existing directory and is not a symbolic link referring to an existing directory". This is fine for the case where an attempt is made to rename a non-directory file, e.g.: mv regular_file new_name/ but I can see no reason that an attempt to rename a directory should fail, e.g.: mv existing_dir new_dir/ or: mv existing_dir/ new_dir/ Indeed, these commands work on Solaris 10. Action: Change "In this case, if target_file ends with a trailing ..." to "In this case, if source_file names a non-directory file and target_file ends with a trailing ..." XSHbug3 ERN 21 pthread_cond_timedwait Accept @ page 1587 line 51027-51034 section pthread_cond_timedwait editorial [gwc pctw timeout] Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required In the description of pthread_cond_timedwait(), a statement about the clock attribute and a paragraph break have been inserted between two closely related sentences. The text should be rearranged in order to reunite the related sentences. Action: In the two paragraphs: The pthread_cond_timedwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. The condition variable shall have a clock attribute which specifies the clock that shall be used to measure the time specified by the abstime argument. When such timeouts occur, pthread_cond_timedwait() shall nonetheless release and re-acquire the mutex referenced by mutex. The pthread_cond_timedwait() function is also a cancellation point. move the sentence beginning "When such timeouts occur" to the end of the first of the paragraphs. XSHbug3 ERN 22 pthread_mutex_lock Accept @ page 1639 line 52741 section pthread_mutex_lock objection [gwc pmtl return] Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The RETURN VALUE section on the pthread_mutex_lock() page states: "The pthread_mutex_trylock() function shall return zero if a lock on the mutex object referenced by mutex is acquired. Otherwise, an error number is returned to indicate the error." This conflicts with the description of the EOWNERDEAD error for pthread_mutex_trylock() which says "The mutex lock shall be acquired by the calling thread". Action: On line 52739 (1st line of RETURN VALUE) change "pthread_mutex_lock() and pthread_mutex_unlock()" to "pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock()" Delete lines 52741-52742 (2nd para of RETURN VALUE). XCUbug3 ERN 3 date Accept It should be noted that this is an enhancement, and should be added SD5, items for consideration for the next revision. It should also be noted that the proposed action does not address all the issues raised in the problem specifications. @ page 2575 line 82893 section date objection {ebb.date} Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission Although the date utility provides an interface similar to the strftime function, there are several things specified only for the latter (some with CX shading), which would be useful from a command line interface. These include: missing specifiers, addition of flags, addition of minimum field width. This aardvark only addresses missing specifiers. An alternative solution might be to couch the entire discussion of the format argument of the date utility in terms of a call to strftime, so that the next time the strftime interface is extended, the date utility implicitly picks up that extension; this would also pick up the '0' and '+' flags as well as minimum field width. Action: At line 82893, insert: %F Date in the format %Y-%m-%d %g The last 2 digits of the week-based year (see %V) as a decimal number [00,99]. %G The week-based year (see %V) as a decimal number (for example, 1977). At line 82903, insert: %R Time in the format %H:%M. At line 82922, insert: %z The offset from UTC in the ISO 8601:2000 standard format (+hhmm or -hhmm), or by no characters if no timezone is determinable. For example, "-0430" means 4 hours 30 minutes behind UTC (west of Greenwich). XSHbug3 ERN 20 fscanf OPEN A proposed change is as follows: p934 31305 change to if any error occurs -> if any error occurs before the first successful assignment This is left open for now. Next meeting ------------ The next call will be on Jan 29th at 16:00 UK time to look at the option to move to bugzilla. The next call after that will be February 12th at 16:00 UK time to carry on with the aardvark. See the calendar for the extensive 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