Austin Group Minutes of the 5 July 2007 Teleconference Austin-371 Page 1 of 1 Submitted by Andrew Josey, The Open Group. July 6, 2007 Attendees Andrew Josey, The Open Group Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Don Cragun , Sun, PASC OR Ulrich Drepper, Red Hat Action item review --------------------- ACTION AI-2005-01-01: Don Cragun to present paper on pathname resolution. OPEN ACTION 2007-02-06: Ulrich to research issue 15 and propose text for XSH intro to explain directory searching, with special respect to the *at() functions. OPEN (Geoff has posted some mail on this, come back to this when Ulrich has the cycles) Ulrich has also now posted some thoughts on this item. It was agreed that we need to close this actions at the September meeting so we can incorporate the changes into D4 Status ------ Andrew to send out the meeting notice for the September F2F Sep 4-7 Tues-> Fri . Officially it cannot be an ISO editors meeting as the ISO FCD ballot started this week and runs for 5 months. The POSIX C++ binding group will meet July 15 in Ottawa. Aardvark Bug Reports -------------------- XCU ERN 153 OPEN XSH ERN 204 regcomp OPEN We need to investigate behaviors We need a sample program to act as a test case. Action: Andrew to email the originator for a test case (Completed by email July 6 2007) XSH ERN 208 pthread_t Accept as marked below Change in 2.9.2 "A conforming implementation is free to reuse a thread ID after ..." to "The lifetime of a thread ID ends after ..." Then add "A conforming implementation is free to reuse a thread ID after its lifetime has ended. If an application attempts to use a thread ID whose lifetime has ended the behavior is undefined." Make the last sentence of the existing para its own paragraph "If a thread is detached, its thread ID is invalid for use as an argument in a call to pthread_detach( ) or pthread_join( )." Add to XRAT, B.2.9.2: New paragraphs: Some applications make the assumption that the implementation can always detect invalid uses of thread IDs of type pthread_t. This is an invalid assumption. Specifically, if pthread_t is defined as a pointer type, no access check needs to be performed before using the ID. As with other interfaces that take pointer parameters, the outcome of passing an invalid parameter can result in an invalid memory reference or an attempt to access an undefined portion of a memory object, cause signals to be sent (SIGSEGV or SIGBUS) and possible termination of the process. This is a similar case to passing an invalid buffer pointer to read(). Some implementations might implement read() as a system call and set an EFAULT error condition. Other implementations might contain parts of read() at user level and the first attempt to access data at an invalid reference will cause a signal to be sent instead. If an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an ESRCH error. This does not imply that implementations are required to return in this case. It is legitimate behavior to send an "invalid memory reference" signal (SIGSEGV or SIGBUS). It is the application's responsibility to use only valid thread IDs and to keep track of the lifetime of the underlying threads. (see also ERN 215 below) XSH ERN 215 ESRCH errors Accept as marked below Delete all ESRCH errors in the pthread* pages (both shall fail and may fail) . Note to editors: There can be more than one on a page (pthread_getschedparam) and its ok to delete them all. When deleting add some rationale to each page. If an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an ESRCH error. XSH ERN 213 getcwd() Accept as marked below Replace the entire DESCRIPTION section with: The getcwd() function shall place a string in the array pointed to by buf, and return buf. The string shall be either an absolute pathname of the current working directory or a string that would be an absolute pathname of the current working directory except that it is too long to be a pathname. The string shall contain no components that are dot or dot-dot, or are symbolic links. If there are multiple strings that getcwd() could place in the array pointed to by buf, one beginning with a single slash and one or more beginning with two slashes, then getcwd() shall place the string beginning with a single slash in the array. The string shall not contain any unnecessary slashes after the leading one or two slashes. The size argument is the size in bytes of the character array pointed to by the buf argument. If buf is a null pointer, the behavior of getcwd() is unspecified. In the ERANGE error (line 16586) change "pathname" to "string". Replace the description of the EACCES error (line 16588) with: Search permission was denied for the current directory, or read or search permission was denied for a directory above the current directory in the file hierarchy. Replace the entire EXAMPLE section (lines 16591-16604) with: The following example uses {PATH_MAX} as the initial buffer size (unless it is indeterminate or very large), and calls getcwd() with progressively larger buffers until it does not give an ERANGE error. #include #include #include ... long path_max; size_t size; char *buf; char *ptr; path_max = pathconf(".", _PC_PATH_MAX); if (path_max == -1) size = 1024; else if (path_max > 10240) size = 10240; else size = path_max; for (buf = ptr = NULL; ptr == NULL; size *= 2) { if ((buf = realloc(buf, size)) == NULL) { ... handle error ... } ptr = getcwd(buf, size); if (ptr == NULL && errno != ERANGE) { ... handle error ... } } ... In APPLICATION USAGE (line 16606) change "None" to: If the string obtained from getcwd() is longer than {PATH_MAX} bytes, it would produce an ENAMETOOLONG error if passed to chdir(). Therefore in order to return to that directory it is necessary to break the string into sections and call chdir() on each section in turn (the first section being an absolute pathname and subsequent sections being relative pathnames). A simpler way to handle saving and restoring the working directory when it may be deeper than {PATH_MAX} bytes in the file hierarchy is to use a file descriptor and fchdir(), rather than getcwd() and chdir(). However, the two methods do have some differences. The fchdir() approach causes the program to restore a working directory even if it has been renamed in the meantime, whereas the chdir() approach restores to a directory with the same name as the original, even if the directories were renamed in the meantime. Since the fchdir() approach does not access parent directories, it can succeed when getcwd() would fail due to permissions problems. In applications conforming to earlier versions of this standard, it was not possible to use the fchdir() approach when the working directory is searchable but not readable, as the only way to open a directory was with O_RDONLY, whereas the getcwd() approach can succeed in this case. In RATIONALE (page 503 line 16608) change: Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined, an application generally cannot supply a buf with size {{PATH_MAX}+1}. to: Since a pathname cannot, by definition, contain more than {PATH_MAX} bytes (including the null terminator), the description is careful to use the word "string" rather than "pathname" to refer to the contents of the array, as it may contain more than {PATH_MAX} bytes. Insert a new paragraph after line 16623: Earlier implementations of getcwd() sometimes generated pathnames like "../../../subdirname" internally, using them to explore the path of ancestor directories back to the root. If one of these internal pathnames exceeded {PATH_MAX} in length, the implementation could fail with errno set to ENAMETOOLONG. This is no longer allowed. Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. Next teleconference meeting will be THURSDAY 19 July 2007. Note that the time will be at 16:00 UK (15:00 UT) local time Dial-in:+1 877-421-0003 Or Int'l +1-770-615-1374 Passcode: 953276 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