Last updated August 22 2008 http://www.opengroup.org/austin/aardvark/latest/xshbug3.txt _____________________________________________________________________________ COMMENT Enhancement Request Number 1 michael.kerrisk:xxxxxxxxx Bug in XSHd5 futimens (rdvk# 1) {utimensat-errs} Wed, 14 May 2008 22:43:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 969 Line: 32433 Section: futimens Problem: 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. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 2 jim:xxxxxxxxxxxx typo in XSHd5.1 getcwd (rdvk# 2) {jmm-getcwd-parens} Sat, 28 Jun 2008 17:50:26 +0200 (16:50 BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: editorial will fix for publication _____________________________________________________________________________ Page: 997 Line: 33460 Section: getcwd Problem: The examples section has excess parentheses: "getcwd()()". Action: On line 33460, change and calls getcwd()() with progressively... to and calls getcwd() with progressively... _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 Jens.Maurer:xxxxxxx Bug in XSHd5.1 pthread_rwlock_destroy( ) (rdvk# 1) {jmaurer-1} Wed, 18 Jun 2008 10:36:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: editorial will fix for publication _____________________________________________________________________________ Page: 1671 Line: 53680 Section: pthread_rwlock_destroy( Problem: syntax error in signature int pthread_rwlock_destroy(pthread_rwlock_t *rwlock, Action: fix the declaration to read: int pthread_rwlock_destroy(pthread_rwlock_t *rwlock); _____________________________________________________________________________ COMMENT Enhancement Request Number 4 tydeman:xxxxxxxxx Bug in XSHd5.1 sigaction() (rdvk# 6) {sigaction-signal} Thu, 24 Jul 2008 17:15:56 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Fix the application usage on sigaction() page 1919 so its consistent with the signal() page Target for TC1 (not interpretation necessary as informative text) _____________________________________________________________________________ Page: 1919 Line: 61039 Section: sigaction() Problem: sigaction() at line 61039 lists abort(), kill(), raise(). While signal() at line 61636 lists abort(), raise(), kill(), pthread_killl(), and sigqueue(). Seems strange to have a different list of functions. Action: Review the list of exceptional functions for signal() and sigaction() to make sure they should be different. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 tydeman:xxxxxxxxx Bug in XSHd5.1 sigaction() (rdvk# 5) {sigaction table} Thu, 24 Jul 2008 17:09:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_Previous Reject_____ Rationale for rejected or partial changes: Fixed in D5.1R _____________________________________________________________________________ Page: 1919 Line: 61041 Section: sigaction() Problem: "listed in the table above" is very hard to find. It is about 1500 pages above. I assume it is the list of async-signal-safe functions. Action: Should be replaced along the lines of page 1937, line 61640 in signal(): "listed in Section 2.4 (page 489)". Also, perhaps the table on page 489 should be given a number. Note: The page and line references are against draft 5 of 4 April 2008. _____________________________________________________________________________ COMMENT Enhancement Request Number 6 mtk.manpages:xxxxxxxxx Bug in XSHd5.1 tgamma (rdvk# 4) {tgamma} Thu, 24 Jul 2008 07:04:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track. The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Target for TC1 Add the following to tgamma (this text comes from exp()): RETURN VALUE If the correct value would cause underflow, and is not representable, a range error may occur, [MX] and either 0.0 (if supported), or [/MX] an implementation-defined value shall be returned. [MX] If the correct value would cause underflow, and is representable, a range error may occur and the correct value shall be returned. [/MX] ERRORS These functions may fail if: Range Error The result underflows. If the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [ERANGE]. If the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the underflow floating-point exception shall be raised. _____________________________________________________________________________ Page: 2105 Line: 66605 Section: tgamma Problem: In Section 7.12.8.4 of the C99 spec, it says: A range error may occur if the magnitude of x is too large or too small. XSH specifies the overflow condition, but does not specify the underflow condition. It should also specify the underflow condition. Action: At line 66605, append the following text: == If the correct value would cause underflow, a range error shall occur and tgamma(), tgammaf(), and tgammal() shall return 0. == (A point about which I'm unsure mathematically is whether the last piece should read: ... shall return 0, with the same sign as the correct value of the function. I'll leave that to the math experts.) ========== At line 66626, append the following text: == Range Error The value underflows. If the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [ERANGE]. If the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the underflow floating-point exception shall be raised. == _____________________________________________________________________________ EDITORIAL Enhancement Request Number 7 nick:xxxxxxxxxx Bug in XSHd5.1 wait (rdvk# 3) {nms-wait-o1} Sat, 28 Jun 2008 00:56:02 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add return 0; /* NOTREACHED */ after line 68919/before line 68920. Target for TC1 _____________________________________________________________________________ Page: 2186 Line: 68919 Section: wait Problem: The example provided declares main as returning "int", but then does not return any value. Action: Add return 0; after line 68919/before line 68920. --last bug number 7