XSH D4R Aardvark Reports Austin-425 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Mar 6, 2008 Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Accept as marked ERN 3 Accept ERN 4 Accept ERN 5 Accept ERN 6 Accept as marked ERN 7 Reject ERN 8 Reject ERN 9 Accept ERN 10 Accept _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 nick:xxxxxxxxxx Bug in XSHd4 SEE ALSO (rdvk# 7) {nms-xref} Tue, 29 Jan 2008 21:29:14 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make the changes Nick suggests except for removal of , and where it says change to , just add to the SEE ALSO The rationale was that often a type might be referred to in a page, and the inclusion of is implicit, so the SEE ALSO is often useful. A detailed pass could be made to consider each interface, however the course above will work. note:Do not add to Synopsis on page 942 _____________________________________________________________________________ Page: 0 Line: 0 Section: SEE_ALSO Proposed Resolution: Accept as marked below Make the changes Nick suggests except for removal of , and where it says change to , just add to the SEE ALSO The rationale was that often a type might be referred to in a page, and the inclusion of is implicit, so the SEE ALSO is often useful. A detailed pass could be made to consider each interface, however the course above will work. Problem: The use of pdf cross-reference hyperlinks greatly improves the usability of the PDF version of the standard. The HTML version also benefits from good hyperlinks. The See Also section for all interfaces should include references to *all* of the header files required in the synopsis section. In other places, multiple header files are no longer required by the synopsis, and have been removed in this or earlier issues. However, the Xref to them is still there in the SEE ALSO list. These should be removed. Action: Page 620, line 21241: add Page 700, line 23701: REMOVE (see change history for issue 6) Page 824, line 27523: REMOVE and (see CH) Page 940, line 31540: REMOVE Page 946, line 31743: REMOVE (consider adding to Synopsis on page 942 to satisfy requirement at line 31613) Page 969, line 32443: add Page 986, line 33101: REMOVE Page 1004, line 33730: REMOVE Page 1008, line 33851: REMOVE Page 1009, line 33883: REMOVE Page 1013, line 33995: REMOVE and Page 1016, line 34109: REMOVE and Page 1018, line 34196: REMOVE Page 1045, line 35008: REMOVE Page 1046, line 35040: REMOVE Page 1048, line 35081: REMOVE Page 1056, line 35297: REMOVE and Page 1060, line 35447: REMOVE and Page 1080, line 36040: REMOVE Page 1168, line 38846: REMOVE Page 1170, line 38894: REMOVE Page 1198, line 39621: REMOVE Page 1261, line 41563: REMOVE Page 1286, line 42283: REMOVE Page 1292, line 42484: REMOVE Page 1353, line 44433: REMOVE Page 1381, line 45381: REMOVE Page 1416, line 46406: add Page 1526, line 49329: CHANGE to Page 1768, line 56593: REMOVE Page 1782, line 57043: REMOVE Page 1804, line 57734: REMOVE and Page 1854, line 59320: REMOVE Page 1869, line 59685: REMOVE Page 1881, line 59927: REMOVE Page 1888, line 60105: REMOVE Page 2072, line 65721: REMOVE Page 2075, line 65776: REMOVE Page 2076, line 65824: REMOVE Page 2080, line 65925: REMOVE Page 2083, line 66011: REMOVE Page 2087, line 66112: REMOVE Page 2088, line 66163: REMOVE Page 2105, line 66708: add Page 2140, line 67703: REMOVE Page 2153, line 68125: REMOVE and Page 2236, line 70387: add _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 gwc:xxxxxxxxxxxxx utime (rdvk# 5) [gwc ENOTDIR errors] Wed, 30 Jan 2008 16:42:43 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Take the action as proposed with the following modification Change "names an existing non-directory file" to "names an existing file that is neither a directory nor a symbolic-link to a directory" _____________________________________________________________________________ Page: 559 Line: 19456 Section: access Problem: The following statement has been added to XBD 4.12 Pathname Resolution: "A pathname that contains at least one non- character and that ends with one or more trailing characters shall not be resolved successfully unless the last pathname component before the trailing characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved." This gives rise to the question of what error number should be reported by functions which cannot resolve a pathname successfully under the conditions described in the above quote. The ERRORS section for each affected function ought to cover these conditions, but there are some omissions. The cases where the last component does not exist are covered by ENOENT errors. The omissions are for some cases where the last component exists but is not a directory (and the function does not give an EEXIST error when the file exists). The appropriate error number for this condition is ENOTDIR. Action: At page 559 line 19456 section access, page 654 line 22159 section chmod, page 658 line 22322 section chown, page 793 line 26496 section fattach, page 814 line 27213 section fdetach, page 886 line 29498 section fpathconf, page 943 line 31631 section fstatat, page 948 line 31813 section fstatvfs, page 955 line 32018 section ftok, page 967 line 32353 section futimens, page 1203 line 39745 section lchown, page 1744 line 55760 section readlink, page 2129 line 67449 section truncate, page 2148 line 67903 section unlink, and page 2156 line 68204 section utime, change: [ENOTDIR] A component of the path prefix is not a directory. to: [ENOTDIR] A component of the path prefix is not a directory, or the path argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. (Note to the editor: in some of these cases the existing text has "path prefix of path"; the replacement text can retain the "of path" if desired. Also, on the chmod and chown pages ENOTDIR should be moved to after ENOENT.) At page 615 line 21057 section bind, change: [ENOTDIR] A component of the path prefix of the pathname in address is not a directory. to: [ENOTDIR] A component of the path prefix of the pathname in address is not a directory, or the pathname in address contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 638 line 21684 section catopen, change: [ENOTDIR] A component of the path prefix of the message catalog is not a directory. to: [ENOTDIR] A component of the path prefix of the message catalog is not a directory, or the pathname of the message catalog contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 689 line 23362 section connect, change: [ENOTDIR] A component of the path prefix of the pathname in address is not a directory. to: [ENOTDIR] A component of the path prefix of the pathname in address is not a directory, or the pathname in address contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 775 line 25859 section exec, change: [ENOTDIR] A component of the new process image file's path prefix is not a directory. to: [ENOTDIR] A component of the new process image file's path prefix is not a directory, or the new process image file's pathname contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 876 line 29118 section fopen, and page 921 line 30852 section freopen, change: [ENOTDIR] A component of the path prefix is not a directory. to: [ENOTDIR] A component of the path prefix is not a directory, or the filename argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 1213 line 40049 section link, change: [ENOTDIR] A component of either path prefix is not a directory. to: [ENOTDIR] A component of either path prefix is not a directory, or the path1 argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 1377 line 45219 section open, change: [ENOTDIR] A component of the path prefix is not a directory, or O_DIRECTORY was specified and the path argument does not name a directory. to: [ENOTDIR] A component of the path prefix is not a directory; or O_CREAT and O_EXCL are not specified, the path argument contains at least one non- character and ends with one or more trailing characters, and the last pathname component names an existing non-directory file; or O_DIRECTORY was specified and the path argument does not name a directory. At page 1751 line 55983 section realpath, change: [ENOTDIR] A component of the path prefix is not a directory. to: [ENOTDIR] A component of the path prefix is not a directory, or the file_name argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. At page 1778 line 56875 section rename, change: [ENOTDIR] A component of either path prefix is not a directory; the old argument names a directory and the new argument names a non-directory file; or the new argument names a nonexistant file and ends with a trailing ('/') character. to: [ENOTDIR] A component of either path prefix is not a directory; or the old argument names a directory and the new argument names a non-directory file; or the old argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file; or the new argument names a nonexistant file, contains at least one non- character, and ends with one or more trailing characters. At page 1843 line 58952 section sendmsg, and page 1846 line 59074 section sendto, change: [ENOTDIR] A component of the path prefix of the pathname in the socket address is not a directory. to: [ENOTDIR] A component of the path prefix of the pathname in the socket address is not a directory, or the pathname in the socket address contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 gwc:xxxxxxxxxxxxx Bug in XSHd4 bsearch (rdvk# 2) [gwc bsearch example] Fri, 1 Feb 2008 16:44:53 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 618 Line: 21171 Section: bsearch Proposed Resolution: Accept Problem: Code layout (indentation). Action: Increase the indentation on the line "free(node.string);" so that it is the same as the previous line. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 drepper:xxxxxxxxxx Bug in XSHd4 initstate() (rdvk# 6) {ud-setstate} Wed, 16 Jan 2008 06:18:07 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Action on Ulrich to file an interp(for prev edition) _____________________________________________________________________________ Page: 1115 Line: 37148 Section: initstate() Proposed Resolution: defer Problem: The setstate() function is defined to take a const char* parameter. I cannot remember when the const was instroduced but it is not correct. setstate() is switching in a buffer for the state of the random() functions and it returns the previous state. This implies that the random state buffer has to be written into. Therefore the const must go. This change must also be run down the interps track. Action: XSH: line 37148: change from char *setstate(const char *state); to char *setstate(char *state); page 1885, line 60001: same change XBD, page 354, line 12009: same change _____________________________________________________________________________ COMMENT Enhancement Request Number 5 gwc:xxxxxxxxxxxxx Bug in XSHd4 pthread_atfork (rdvk# 4) [gwc pthread_atfork rationale] Mon, 4 Feb 2008 15:26:23 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1525 Line: 49285 Section: pthread_atfork Proposed Resolution: Accept Problem: Additions have been made to the RATIONALE for pthread_atfork() to explain why the child is restricted to async-signal-safe interfaces. However, some of the old rationale text still (misleadingly) implies that pthread_atfork() can be used in the way originally intended. For example, "The pthread_atfork() function provides multi-threaded libraries with a means to protect themselves from innocent application programs that call fork()". The affected text needs to be recast as a historical record. Action: Change The pthread_atfork() function provides multi-threaded libraries with a means to protect themselves from innocent application programs that call fork(), and it provides multi-threaded application programs with a standard mechanism for protecting themselves from fork() calls in a library routine or the application itself. The expected usage is that the prepare handler acquires all mutex locks and the other two fork handlers release them. For example, an application can supply a prepare routine that acquires the necessary mutexes the library maintains and supply child and parent routines that release those mutexes, thus ensuring that the child gets a consistent snapshot of the state of the library (and that no mutexes are left stranded). to The pthread_atfork() function was intended to provide multi-threaded libraries with a means to protect themselves from innocent application programs that call fork(), and to provide multi-threaded application programs with a standard mechanism for protecting themselves from fork() calls in a library routine or the application itself. The expected usage was that the prepare handler would acquire all mutex locks and the other two fork handlers would release them. For example, an application could have supplied a prepare routine that acquires the necessary mutexes the library maintains and supplied child and parent routines that release those mutexes, thus ensuring that the child would have got a consistent snapshot of the state of the library (and that no mutexes would have been left stranded). On line 49304 change Alternatively, some libraries might be able to supply to Alternatively, some libraries might have been able to supply On line 49306 change This is approach is not possible to This approach is not possible At line 49313 change The parent process may avoid this by explicit code that acquires and releases locks critical to the child via pthread_atfork(). In addition, any critical threads need to be recreated ... to The intention was that the parent process could have avoided this by explicit code that acquires and releases locks critical to the child via pthread_atfork(). In addition, any critical threads would have needed to be recreated ... _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 gwc:xxxxxxxxxxxxx Bug in XSHd4 pthread_cond_timedwait (rdvk# 3) [gwc pctw EPERM ub] Fri, 1 Feb 2008 16:46:24 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change from: "They shall be called with mutex locked by the calling thread or undefined behavior results." To: The application shall ensure that these functions are called with mutex locked by the calling thread; otherwise an error (for PTHREAD_MUTEX_ERRORCHECK and robust mutexes) or undefined behavior (for other mutexes) results. _____________________________________________________________________________ Page: 1581 Line: 50871 Section: pthread_cond_timedwait Proposed Resolution: Accept as marked below Change from: "They shall be called with mutex locked by the calling thread or undefined behavior results." To: The application shall ensure that these functions are called with mutex locked by the calling thread; otherwise an error (for PTHREAD_MUTEX_ERRORCHECK and robust mutexes) or undefined behavior (for other mutexes) results. Problem: A change has been made to pthread_cond_timedwait() and pthread_cond_wait() to make the EPERM error "shall fail" for PTHREAD_MUTEX_ERRORCHECK and robust mutexes. This error is returned when the calling thread does not own the mutex. However, in the first paragraph of the DESCRIPTION of the functions, the following text appears: "They shall be called with mutex locked by the calling thread or undefined behavior results." This needs to be altered so that it only applies to mutexes for which the EPERM error is not mandated. Action: Change "or undefined behavior results" to "or an error (for PTHREAD_MUTEX_ERRORCHECK and robust mutexes) or undefined behavior (for other mutexes) results" _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 ebb9:xxxxxxx Bug in XSHd4 rename (rdvk# 8) {ebb.rename} Wed, 20 Feb 2008 16:46:23 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The rules in pathname resolution are clear and intentional. All systems conforming to the current standard behave as per the latest text in the draft standard. Draft 4 more clearly explains current existing behavior. _____________________________________________________________________________ Page: 1776 Line: 56800 Section: rename Proposed Resolution:Reject The rules in pathname resolution are clear and intentional. All systems conforming to the current standard behave as per the latest text in the draft standard. Draft 4 more clearly explains current existing behavior. Problem: The behavior of rename on symlinks to directories in the presence of trailing slashes is confusing enough that Linux, Solaris, and BSD have different behaviors; this is compounded by the fact that the requirements for pathname resolution changed in this draft. Consider: $ mkdir A $ ln -s A B $ mv B/ C One reading shows the following behavior: - mv obeys the requirements of rename("B/", "C") (XCU 97163). - rename performs path resolution on "B/". A symbolic link is encountered ("B"), however, the pathname has a trailing slash, so resolution is not complete (XBD 3019). - the symlink is followed, and path resolution continues on "A/" (XBD 3024). - the pathname contains a non-slash and ends in a slash, but A names an existing directory, so pathname resolution is complete (XBD 3008). - the old argument resolves to a directory, not a symlink, so the operation is not performed on B (XSH 56803) - the new argument does not resolve to an existing directory, so A must be renamed to C, leaving B as a broken symlink (XSH 56813). This behavior is followed by OpenBSD 4.0. However, Linux and Solaris 8 argue that leaving B dangling merely because it was specified with a trailing slash is confusing to the user, and fail the rename operation with ENOTDIR. Technically, this is permitted by XSH 16178: "Implementations... may generate errors included in this list under circumstances other than those described here". Additionally, another aardvark is already proposing adding the wording that rename may fail with ENOTDIR if "the old argument contains at least one non- character and ends with one or more trailing characters and the last pathname component names an existing non-directory file", and one can argue that a symbolic link is an existing non-directory file. However, both of these arguments are rather weak, and it would be nice to explicitly permit Linux behavior in rename. This proposal augments the specification to allow either behavior (renaming the linked-to directory, or failing with ENOTDIR); Linux' behavior then matches: - mv obeys the requirements of rename("B/", "C") (XCU 97163). - rename temporarily strips the trailing slash on the old argument while performing path resolution on "B" (XSH proposal). - B is the last component, does not have a trailing slash, and rename operates directly on symlinks, so resolution is complete (XBD 3017). - the old argument resolves to a symlink, but because a trailing slash was present, the rename call fails with ENOTDIR (XSH proposal) Action: At line XSH 56800, add, with CX shading: If the old argument contains at least one non- character and ends with one or more trailing characters, it is implementation-defined whether rename() will fail if pathname resolution without the training characters resolves to a symbolic link. immediately prior to the sentence: If the new argument does not resolve to an existing file of type directory and the new argument contains at least one non- character and ends with one or more trailing characters after all symbolic links have been processed, rename( ) shall fail. At line 56907, add a paragraph with CX shading (rename and renameat may fail): [ENOTDIR] The old argument contains at least one non- character and ends with one or more trailing characters, but the last path component without the trailing characters resolves to a symbolic link. (note that another aardvark touches the ENOTDIR paragraph at line 56875, so consideration should be made whether this should be made a shall fail error condition). _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 ebb9:xxxxxxx Bug in XSHd4 rmdir (rdvk# 9) {ebb.rmdir} Wed, 20 Feb 2008 17:14:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: See ERN 7 for rationale _____________________________________________________________________________ Page: 1785 Line: 57125 Section: rmdir Proposed Resolution: Reject See the similar bug against rename Problem: The behavior of rmdir on symlinks to directories in the presence of trailing slashes is confusing enough that Linux, Solaris, and BSD have different behaviors; this is compounded by the fact that the requirements for pathname resolution changed in this draft. Consider: $ mkdir A $ ln -s A B $ rmdir B/ One reading shows the following behavior: - rmdir obeys the requirements of rmdir("B/") (XCU 104270). - rmdir performs path resolution on "B/". A symbolic link is encountered ("B"), however, the pathname has a trailing slash, so resolution is not complete (XBD 3019). - the symlink is followed, and path resolution continues on "A/" (XBD 3024). - the pathname contains a non-slash and ends in a slash, but A names an existing directory, so pathname resolution is complete (XBD 3008). - the old argument resolves to a directory, not a symlink, so the operation need not fail (XSH 57125), so A is deleted, leaving B as a broken symlink. A raw rename(2) on OpenBSD 4.0 follows this behavior, however, rmdir(1) strips the trailing slash and wrongly calls rmdir("B") rather than rmdir("B/"), failing with ENOTDIR. And on Linux and Solaris 8, rmdir(1) correctly calls rmdir("B/") but the system call argues that leaving B dangling merely because it was specified with a trailing slash is confusing to the user, and fails the operation with ENOTDIR. Technically, this is permitted by XSH 16178: "Implementations... may generate errors included in this list under circumstances other than those described here". However, this argument is rather weak, and it would be nice to explicitly require the ENOTDIR that most implementations use. Although rmdir(2) was not changed in this draft, this aardvark is justified based on internal consistency with the changes to pathname resolution in XBD 4.12. This proposal invalidates the existing behavior of BSD rename(2), but at the same time, makes the currently invalid behavior of BSD rename(1) valid. Action: Rewrite the paragraph at XSH 57125 from: If path names a symbolic link, then rmdir() shall fail and set errno to [ENOTDIR]. to: If path contains at least one non- character, and ends with one or more characters, pathname resolution shall be performed with all trailing characters removed. If the resolved path names a symbolic link, then rmdir() shall fail and set errno to [ENOTDIR]. _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 gwc:xxxxxxxxxxxxx Bug in XSHd4 sysconf (rdvk# 1) [gwc sysconf uucp] Thu, 31 Jan 2008 17:07:54 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2056 Line: 65185 Section: sysconf Proposed Resolution: Accept Problem: _SC_XOPEN_UUCP is missing from the table. Although no change has been made since the previous draft, either here or in where _SC_XOPEN_UUCP is listed, this change should be considered to be in scope on the grounds of making the document internally consistent. Action: After line 65185 add: _XOPEN_UUCP _SC_XOPEN_UUCP _____________________________________________________________________________ Editorial Enhancement Request Number 10 gwc:xxxxxxxxxxxxx Bug in XSHd4 sysconf (rdvk# 1) [gwc mkdtemp ENOENT] Tue, 5 Mar 2008 17:07:54 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1287 Line: 42341 Section: mkdtemp Problem: The description of ENOENT on the mkdtemp() page has some extraneous text referring to a non-existent "path" argument. Action: Delete "or path is an empty string".