Minutes of the 15 May 2008 Teleconference Austin-432 Page 1 of 1 Submitted by Andrew Josey, The Open Group. May 16 , 2008 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Larry Dwyer, HP (partial) Ulrich Drepper, Red Hat Draft 5.1 has been released. The IEEE ballot is underway and runs until May 29th. If we run the recirculation ballot at IEEE and receive no new comments, then we are complete at IEEE. If we receive new comments that need to be addressed, then we will need to resolve them and recirculate again. The ISO disposition of comments was sent to Sally Seitz at ANSI and has been distributed. The draft 5.1 document has subsequently been submitted to Sally for FDIS balloting. ** Aardvark We picked up on the 2004 aardvark reports. XSH ERN 238 fputc SIGXFSZ OPEN Leave open for now as we need to enumerate the set of changes. Action: Don to look at this and propose a set of changes (and was waiting for draft 5.1). XSH ERN 240 putenv environ Accept as marked below Send down the Interps track, the standard is unclear Remove from DESCRIPTION the last sentence of para 1 36660 page 1170 "The space used by string is no longer used once a new string which defines name is passed to putenv()." Add a new paragraph after line 36661: "If the application directly modifies environ or the pointers to which it points, the behavior of putenv() is undefined." Add to APPLICATION USAGE after 36685 Although the space used by string is no longer used once a new string which defines name is passed to putenv(), if any thread in the application has used getenv() to retrieve a pointer to this variable, it should not be freed by calling free(). If the changed environment variable is one known by the system (such as the locale environment variables) the application should never free the buffer used by earlier calls to putenv() for the same variable. Also make similar changes to getenv, setenv, unsetenv as follows: for setenv/getenv/unsetenv insert the word "directly" into "If the application modifies environ or the pointers" so it becomes "If the application *directly* modifies environ or the pointers" XCU ERN 180 pax Accept as marked below Add the following as a new paragraph to the pax APPLICATION USAGE section after (draft 5 of the revision page and line numbers) P3031, L100222: When all of the following are true: 1. a file of type directory is being placed into an archive, 2. the ustar archive format is being used, 3. the pathname of the directory is less than or equal to 155 bytes long (it will fit in the prefix field in the ustar header block), and 4. the last component of the pathname of the directory is longer than 100 bytes long (it will not fit in the name field in the ustar header block) some implementations of the pax utility will place the entire directory pathname in the prefix field, set the name field to an empty string, and place the directory in the archive. Other implementations of the pax utility will give an error under these conditions because the name field is not large enough to hold the last component of the directory name. This standard allows either behavior. However, when extracting a directory from a ustar format archive, this standard requires that all implementations be able to extract a directory even if the name field contains an empty string as long as the the prefix field does not also contain an empty string. Add this change to the list of stuff to be done in TC1 of the revision. (it does not need an interp for informative) * Aardvark against the REVISION Andrew will need to create a separate aarvark log for items only in the new revision. The first issue had come in below XSH2008 ERN 1 futimens Accept @ page 969 line 32433 section futimens comment {utimensat-errs} Problem: (Draft 5.1 line numbers) The text describing the EPERM error under futimens() appears to be faulty. Consider the following table, which describes the three parameters affecting the success or failure of these interfaces. In the table, the columns are: [a] Is the time argument NULL (or in the case of futimens() and utimnensat() points to a structure in which both fields are UTIME_NOW or both are UTIME_OMIT), or does it point to a structure containing timestamps? [b] Does the caller's effective UID match the owner of the file? [c] Is the file writable by the caller's effective UID? [a] [b] [c] times file file arg. UID is NULL owner writable Result !NULL !owner !writable N o w success N o !w success N ! w success N !o !w EACCES [1] !N o w success !N o !w success !N !o w EPERM [2] !N !o !w EPERM [3] The fourth column shows the expected result of calling the interface. However, the text describing the errors does not cover all three error cases above: Error case [1] is covered by the EACCES description: [EACCES] The times argument is a null pointer, or both tv_nsec values are UTIME_NOW, and the effective user ID of the process does not match the owner of the file and write access is denied. Error case [2] is covered by the EPERM description: [EPERM] The times argument is not a null pointer, does not have both tv_nsec fields set to UTIME_NOW, does not have both tv_nsec fields set to UTIME_OMIT, the calling process effective user ID has write access to the file but does not match the owner of the file, and the calling process does not have appropriate privileges. Error case [3] is not covered by either of the above descriptions. Lines 32400-32403 of the draft say : Only a process with the effective user ID equal to the user ID of the file or with appropriate privileges may use futimens() or utimensat() with a non-null times argument that does not have both tv_nsec fields set to UTIME_NOW and does not have both tv_nsec fields set to UTIME_OMIT. Looking at these lines suggests that the text for the EPERM error should remove discussion of write access to the file, since the error applies regardless of whether the file is writable. Action: Replace lines 32431 to 32435 with the following: [EPERM] The times argument is not a null pointer, does not have both tv_nsec fields set to UTIME_NOW, does not have both tv_nsec fields set to UTIME_OMIT, the calling process effective user ID does not match the owner of the file, and the calling process does not have appropriate privileges. * Other businnes Don raised an issue about scanf() and will raise through the test suite interpretations process if necessary. * Interpretations Andrew will check the interps status to see if any should be finalized. (open action carried forward) Next meeting ------------ The next call will be June 5th at 16:00 UK time. to carry on with the aardvark 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