Austin Group Minutes of the 13 Sep 2007 Teleconference Austin-397 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Sep 16, 2007 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Nick Stoughton, USENIX, ISO/IEC OR Geoff Clare, The Open Group Mats Wichmann, Intel Eric Blake Apologies Mark Brown, IBM, TOG OR Ulrich Drepper, Red Hat We picked up at the recent interpretations. Austin-148 wordexp() thread safety / XSHbug2 ERN 225 Geoff was concerned that we had this interpretation wrong. He believes the following text from environ/exec covers some of the situation: "Conforming multi-threaded applications shall not use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable. A call to any function dependent on any environment variable shall be considered a use of the environ variable to access that environment variable." so we should remove to text to 2.9.1 in AI-148 and changes to setlocale(). The additional changes were identified to AI-148/XSH ERN 225 (see those for the complete revised text) We ought to add a note to 2.9.1 "Since multi-threaded applications are not allowed to use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable, any function dependent on any environment variable is not thread safe if another thread is modifying the environment, see to exec in XSH" Remove last para of getenv() RATIONALE The POSIX Threads Extension states that multi-threaded applications must not modify environ directly, and that POSIX.1-200x is providing functions which such applications can use in the future to manipulate the environment in a thread-safe manner. Thus, moving away from application use of environ is desirable from that standpoint as well. Add to Future Directions in getenv() A future revision may add one or more functions to access and modify the environment in a thread-safe manner. An extra para to APP USAGE of wordexp() This standard does not require the wordexp() function to be thread safe if passed an expression referencing an environment variable and while any other thread is concurrently modifying any environment variable (xref to exec in XSH). Action: Andrew to update Austin interp 148 and XSH ERN 225 Completed Austin-164 / XCUbug2.txt ERN 57 ------------------------------------- Eric raised concerns about the notes to the editors for interp Austin-164 in mail sequence 10998. Specifically the paragraph: Add to RATIONALE for ln The specification ensures that 'ln a a' with or without the -f option will not unlink the file a. Earlier versions of the standard were unclear in this case. belongs to XCU ERN 166 (interp 169), not XCU ERN 57 (interp 164). It was agreed that Andrew should update the notes to the editors sections of interpretations Austin-169 and Austin-164 appropriately. Austin-016 Geoff had submitted some comments on this interpretation. There is a missing word in the text starting "Change the fourth paragraph of the description of the Pathname Resolution general concept ...". Insert "that" where indicated: Interfaces using pathname resolution may specify additional constraints* when a pathname [that] does not name an existing directory contains at least one non-slash character and contains one or more trailing slashes. Also the associated footnote refers to rm but it should refer to mv: * The only interfaces that further constrain pathnames in this standard are the rename() and renameat() functions (see XSH rename(), on page xxx) and the rm utility (see XCU rm, on page xxx). Change the two occurrences of "rm" to "mv". An additional change was also indentified for XSH mkdir(). On XSH mkdir DESCRIPTION. Add a new sentence after "The mkdir( ) function shall create a new directory with name path." If path resolves to a symbolic link , mkdir shall expand the symbolic link creating the directory named by the final component of the symlink Andrew will update the notes to editors section of Austin-016. Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. The next meeting is the 20th September, 15:30 start. See http://www.opengroup.org/austin/. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin 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