Last updated June 26 2009 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: Target for TC1 (we will need an interpretation) On signal() D5.1R pg 1937 61636 replace the para with [CX]If the process is multithreaded[/CX], or if the process is single threaded and a signal handler is executed other than as the result of: * the process calling abort(), raise(), [CX]kill(), pthread_kill(), or sigqueue()[/CX] to generate a signal that is not blocked, or * [CX]a pending signal being unblocked and being delivered before the call that unblocked it returns[/CX] the behavior is undefined if the signal handler refers to any object [CX]other than errno[/CX] with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or if the signal handler calls any function defined in this standard other than [CX]one of the functions listed in Section 2.4 (on page xxx)[/CX]. Also copy the above to 2.4.3 without CX shading Replacing 16719-16721 "When signal-catching functions are invoked asynchronously with process execution, the behavior of some of the functions defined by this volume of POSIX.1-200x is unspecified if they are called from a signal-catching function." and change the last piece of the new replacement to in this standard other than one of the functions listed in the following table: also delete the paragraph in APP USAGE On sigaction Page: 1919 Line: 61039 _____________________________________________________________________________ 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 This is a cross volume change All page and line numbers are for draft 5.1. Changes to XBD ... At page 9 line 246 replace the description of the MX code with: MX IEC 60559 Floating-Point The functionality described is optional. The functionality described is mandated by the ISO C standard only for implementations that define __STDC_IEC_559__. and add an MXX code after it: MXX IEC 60559 Floating-Point Extension The functionality described is part of the IEC 60559 Floating-Point option, but is an extension to the ISO C standard. (The "part of" here is because the functionality provided by both MX and MXX is available when __STDC_IEC_559__ is defined. Effectively the two together form a single option.) Note that the above changes include removal of the second paragraph of the MX description: Where applicable, functions are marked with the MX margin legend in the SYNOPSIS section. Where additional semantics apply to a function, the material is identified by use of the MX margin legend. (This is because there are no functions whose SYNOPSIS has MX shading, so there is no need to distinguish between MX markers in the SYNOPSIS and those elsewhere.) Changes to XSH ... At P593 L20443 (asin), P595 L20501 (asinh), P599 L20603 (atan), P605 L20752 (atanh), P790 L26409 (expm1), P1249 L41188 (log1p), P1958 L62217 (sin), P1960 L62286 (sinh), P2074 L65711 (tan) and P2076 L65793 (tanh) change: [MX] If x is subnormal, a range error may occur and x should be returned.[/MX] to (substituting the appropriate function names for asin(), asinf() and asinl()): [MX] If x is subnormal, a range error may occur[/MX] [MXX] and x should be returned.[/MXX] [MX] If x is not returned, asin(), asinf(), and asinl() shall return an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively.[/MX] At P601 L20660 (atan2) change: [MX] If the result underflows, a range error may occur and y/x should be returned.[/MX] to: If the correct value would cause underflow, a range error may occur, and atan2(), atan2f(), and atan2l() shall return an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. [MXX] If IEC 60559 Floating-Point is supported, y/x should be returned.[/MXX] At P765 L25519 (erf) change: [MX] If x is subnormal, a range error may occur, and 2 * x/sqrt(pi) should be returned.[/MX] to: If the correct value would cause underflow, a range error may occur, and erf(), erff(), and erfl() shall return an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. [MXX] If IEC 60559 Floating-Point is supported, 2 * x/sqrt(pi) should be returned.[/MXX] At P767 L25583 (erfc) change: If the correct value would cause underflow and is not representable, a range error may occur and [MX] either 0.0 (if representable), or[/MX] an implementation-defined value shall be returned. to: If the correct value would cause underflow, [MXX]and is not representable[/MXX], a range error may occur, and erfc(), erfcf(), and erfcl() shall return [MXX] 0.0, or [/MXX] (if IEC 60559 Floating-Point is not supported) an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. At P767 L25589 (erfc) change MX shading to MXX for: If the correct value would cause underflow and is representable, a range error may occur and the correct value shall be returned. At P786 L26270 (exp), P788 L26347 (exp2), P870 L28890 (fmod), P1210 L39939 (ldexp), P1518 L49006 (pow) and P2074 L65707 (tan) change: If the correct value would cause underflow, and is not representable, a range error may occur, and [MX] either 0.0 (if supported), or[/MX] an implementation-defined value shall be returned. to (substituting the appropriate function names for exp(), expf() and expl()): If the correct value would cause underflow, [MXX]and is not representable[/MXX], a range error may occur, and exp(), expf(), and expl() shall return [MXX] 0.0, or [/MXX] (if IEC 60559 Floating-Point is not supported) an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. At P1795 L57424 (scalbln) change: If the correct value would cause underflow, and is not representable, a range error may occur, and [MX] either 0.0 (if supported), or[/MX] an implementation-defined value shall be returned. to: If the correct value would cause underflow, [MXX]and is not representable[/MXX], a range error may occur, and scalbln(), scalblnf(), scalblnl(), scalbn(), scalbnf(), and scalbnl() shall return [MXX] 0.0, or [/MXX] (if IEC 60559 Floating-Point is not supported) an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, LDBL_MIN, DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. At P786 L26276 (exp), P788 L26353 (exp2), P870 L28899 (fmod), P1210 L39943 (ldexp), P1519 L49029 (pow), P1795 L57429 (scalbln) and P2074 L65714 (tan) change MX shading to MXX for: If the correct value would cause underflow, and is representable, a range error may occur and the correct value shall be returned. At P818 L27345 (fdim) change: If x-y is positive and underflows, a range error may occur, and either (x-y) (if representable), [XSI] or 0.0 (if supported),[/XSI] or an implementation-defined value shall be returned. to: If the correct value would cause underflow, a range error may occur, and fdim(), fdimf(), and fdiml() shall return [MXX] the correct value, or [/MXX] (if IEC 60559 Floating-Point is not supported) an implementation-defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. At P819 L27364 (fdim) delete from APPLICATION USAGE: On implementations supporting IEEE Std 754-1985, x-y cannot underflow, and hence the 0.0 return value is shaded as an extension for implementations supporting the XSI option rather than an MX extension. At P1098 L36650 (hypot) change MX shading to MXX for: If both arguments are subnormal and the correct result is subnormal, a range error may occur and the correct result is returned. and change "is returned" to "shall be returned". At P1196 L39586 (j0) add MXX shading to: If x is NaN, a NaN shall be returned. At P1367 L44844 (nextafter) change: [MX] If x!=y and the correct function value is subnormal, zero, or underflows, a range error shall occur, and either the correct function value (if representable) or 0.0 shall be returned.[/MX] to: [MX] If x!=y and the correct function value is subnormal, zero, or underflows, a range error shall occur, and[/MX] [MXX] the correct function value (if representable) or[/MXX] [MX] 0.0 shall be returned.[/MX] At P2105 L66604 (tgamma) add: If the correct value would cause underflow, [MXX]and is not representable[/MXX], a range error may occur, and tgamma(), tgammaf(), and tgammal() shall return [MXX] 0.0, or [/MXX] (if IEC 60559 Floating-Point is not supported) an implementation- defined value no greater in magnitude than DBL_MIN, FLT_MIN, and LDBL_MIN, respectively. [MXX] If the correct value would cause underflow, and is representable, a range error may occur and the correct value shall be returned.[/MXX] At P2106 L66636 (tgamma) add: 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. At P2274 L71531 (y0) add MXX shading to: If x is NaN, a NaN shall be returned. _____________________________________________________________________________ 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. _____________________________________________________________________________ COMMENT Enhancement Request Number 8 nick:xxxxxxxxxx Bug in XSHd5.1 pthread_mutex_init (rdvk# 2) {nms-static-pthread} Wed, 17 Sep 2008 19:48:52 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We accepted the proposed change and in addition the following changes need to be applied: Draft 5.1R XSH: Delete "that are statically allocated" on p1582 line 50881 Delete "that are statically allocated" on p1671, lines 53705 XRAT: Delete "statically allocated" on page 3576 line 121175 _____________________________________________________________________________ Page: 1628 Line: 52378 Section: pthread_mutex_init Problem: The current requirements for pthread_mutex_init() were developed at a time when the C standard in force was C89, and as a result restrict initialization of mutex objects via the initializer PTHREAD_MUTEX_INITIALIZER to statically allocated objects only. C99 now permits structure copying, thus allowing PTHREAD_MUTEX_INITIALIZER to be used at other times. (Note, this aardvark is an action arising from the recent P1003.27 POSIX-C++ WG meeting, and is also relevant to the ISO C++ standard in development). Action: At line 52378, delete the words "that are statically allocated". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 9 nick:xxxxxxxxxx Bug in XSHd5.1 pthread_rwlock_init (rdvk# 3) {NMS-pthread_rwlock} Sun, 14 Sep 2008 20:46:23 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1671 Line: 53683 Section: pthread_rwlock_init Problem: In XBD the static initializer PTHREAD_RWLOCK_INITIALIZER is required for all implementations (XBD page xx line yy). However, in the XSH pthread_rwlock_init() function, its use is XSI shaded. It is my belief that this initializer should be in the base requirement (as described in XBD) Action: At lines 53683 and 53704-53707 remove the XSI shading (If an interp is required, the standard is ambiguous) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 gwc:xxxxxxxxxxxxx Bug in XSHd5.1 stpncpy (rdvk# 1) [gwc stpncpy return] Thu, 18 Sep 2008 10:49:35 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2021 Line: 64027 Section: strncpy Problem: There is a typographic error in: "If a NUL character is written to the destination, the stpncpy() function shall return the address of the first such NUL character. Otherwise, it shall return &s2[n]." The "s2" should obviously be "s1". Action: Change "s2" to "s1". _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 nick:xxxxxxxxxx Bug in XSHd5.1 Pointer Types (rdvk# 1) {NMS-funcptr} Wed, 10 Sep 2008 21:05:32 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: After the sentence ending on line 18890, add the following: If a pointer to an object or incomplete type is converted to a pointer to void and then to a pointer to a function type the behavior is undefined., If a pointer to a function type is converted to a pointer to void and then to a pointer to an object or an incomplete type the behaviour is undefined. _____________________________________________________________________________ Page: 541 Line: 18886 Section: Pointer Problem: In order to support the dynamic library functions (and dlsym() in particular), POSIX extends the C standard to require that a pointer to a function can be stored in a pointer to void. This explicit extension opens the door to permit conversion (via other promises in the C standard) of a pointer to a data object into a pointer to a function, thus requiring code such as below to work: char buf[1024]; void *p; int (*f)(void); // assemble instructions into buf p = buf; f = p; f(); In practice, many implementations will forbid execution of data in this form, as it is frequently a source of security vulnerabilities. Similarly, it need not necessarily be supported to try to examine the instructions that make a function by casting (or converting via a void *) a pointer-to-function into a pointer-to-object. The intent is simply to permit dlsym to use a void * as its return type. Action: After the sentence ending on line 18890, add the following: If a pointer to an object or incomplete type is converted to a pointer to void and then to a pointer to a function type, or vice-versa, the behaviour is undefined. _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 gwc:xxxxxxxxxxxxx Bug in XSHd5.1 basename (rdvk# 2) [gwc static data] Tue, 28 Oct 2008 12:12:45 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 614 Line: 20984 Section: basename Problem: Defect code : 1. Error The issue identified for setlocale() in aardvark XSH ERN 250 against the 2004 edition of the standard also affects several other functions. These are functions that are allowed to overwrite returned static data, but should also be allowed to use an internally reallocated buffer for the data. In some cases the statement that returned data may be overwritten is in APPLICATION USAGE. In these cases the proposed replacement is in normative text. Action: [Page and line numbers are for draft 5.1.] basename: P614 L20984 Change "The basename() function may modify the string pointed to by path, and may return a pointer to static storage that may then be overwritten by a subsequent call to basename()." to "The basename() function may modify the string pointed to by path, and may return a pointer to internal storage. The returned pointer might be invalidated or the storage might be overwritten by a subsequent call to basename()." ctermid: P713 L24020 Change "If s is a null pointer, the string shall be generated in an area that may be static (and therefore may be overwritten by each call), the address of which shall be returned. Otherwise, ..." to "If s is a null pointer, the string shall be generated in a area that may be static, the address of which shall be returned. The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to ctermid(). If s is not a null pointer, ..." dirname: P725 L24385 Change "The dirname() function may modify the string pointed to by path, and may return a pointer to static storage that may then be overwritten by subsequent calls to dirname()." to "The dirname() function may modify the string pointed to by path, and may return a pointer to internal storage. The returned pointer might be invalidated or the storage might be overwritten by a subsequent call to dirname()." dlerror: P730 L24547 Add a new paragraph to the RETURN VALUE section: "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to dlerror()." dlerror: P730 L24560 Delete "The messages returned by dlerror() may reside in a static buffer that is overwritten on each call to dlerror(). Application code should not write to this buffer. Programs wishing to preserve an error message should make their own copies of that message." getgrent: P747 L25066 section endgrent Change "The return value may point to a static area which is overwritten by a subsequent call to getgrgid(), getgrnam(), or getgrent()." to "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getgrgid(), getgrnam(), or getgrent()." gethostent: P749 L25126 section endhostent Add a new paragraph to the RETURN VALUE section: "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to gethostent()." gethostent: P749 L25132 section endhostent Change "The gethostent() function may return pointers to static data, which may be overwritten by subsequent calls to any of these functions." to "None" getnet*: P751 L25180 section endnetent Add a new paragraph to the RETURN VALUE section: "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getnetbyaddr(), getnetbyname(), or getnetent()." getnet*: P752 L25186 section endnetent Change "The getnetbyaddr(), getnetbyname(), and getnetent() functions may return pointers to static data, which may be overwritten by subsequent calls to any of these functions." to "None" getproto*: P753 L25235 section endprotoent Add a new paragraph to the RETURN VALUE section: "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getprotobyname(), getprotobynumber(), or getprotoent()." getproto*: P754 L25241 section endprotoent Change "The getprotobyname(), getprotobynumber(), and getprotoent() functions may return pointers to static data, which may be overwritten by subsequent calls to any of these functions." to "None" getpwent: P755 L25276 section endpwent Add a new paragraph to the RETURN VALUE section: "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getpwuid(), getpwnam(), or getpwent()." getpwent: P755 L25283 section endpwent Delete from the ERRORS section: "The return value may point to a static area which is overwritten by a subsequent call to getpwuid(), getpwnam(), or getpwent()." getserv*: P758 L25367 section endservent Add a new paragraph to the RETURN VALUE section: "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getservbyname(), getservbyport(), or getservent()." getserv*: P759 L25375 section endservent Delete "The getservbyname(), getservbyport(), and getservent() functions may return pointers to static data, which may be overwritten by subsequent calls to any of these functions." getenv: P1008 L33858 Change "The string pointed to may be overwritten by a subsequent call to getenv(), [CX]setenv(), unsetenv(),[/CX] [XSI]or putenv()[/XSI] but shall not be overwritten by a call to any other function in this volume of POSIX.1-200x." to "[CX]The returned string pointer might be invalidated or[/CX] the string content might be overwritten by a subsequent call to getenv(), [CX]setenv(), unsetenv(),[/CX] [XSI]or putenv()[/XSI] but they shall not be affected by a call to any other function in this volume of POSIX.1-200x." getgrgid: P1014 L34026 Change "The return value may point to a static area which is overwritten by a subsequent call to getgrent(), getgrgid(), or getgrnam()." to "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getgrent(), getgrgid(), or getgrnam()." getgrnam: P1018 L34154 Change "The return value may point to a static area which is overwritten by a subsequent call to getgrent(), getgrgid(), or getgrnam()." to "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getgrent(), getgrgid(), or getgrnam()." getlogin: P1029 L34474 Change "The return value from getlogin() may point to static data whose content is overwritten by each call." to "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to getlogin()." getpwnam: P1058 L35324 Change "The return value may point to a static area which is overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid()." to "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid()." getpwuid: P1061 L35457 Change "The return value may point to a static area which is overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid()." to "The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid()." localeconv: P1235 L40722 Change "The application shall not modify the structure pointed to by the return value which may be overwritten by a subsequent call to localeconv(). In addition, calls to setlocale() with the categories LC_ALL, LC_MONETARY, or LC_NUMERIC or calls to uselocale() which change the categories LC_MONETARY or LC_NUMERIC may overwrite the contents of the structure." to "The application shall not modify the structure to which the return value points, [CX]nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or[/CX] the structure [CX]or the storage areas[/CX] might be overwritten by a subsequent call to localeconv(). In addition, [CX]the returned pointer, and pointers within the structure, might be invalidated or[/CX] the structure [CX]or the storage areas[/CX] might be overwritten by subsequent calls to setlocale() with the categories LC_ALL, LC_MONETARY, or LC_NUMERIC, [CX]or by calls to uselocale() which change the categories LC_MONETARY or LC_NUMERIC[/CX]." nl_langinfo: P1375 L45104 Delete "Calls to setlocale() with a category corresponding to the category of item (see ), or to the category LC_ALL, may overwrite the array pointed to by the return value. Calls to uselocale() which change the category corresponding to the category of item may overwrite the array pointed to by the return value." nl_langinfo: P1375 L45113 Change "This pointer may point to static data that may be overwritten on the next call to either function." to "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to either function, by subsequent calls to setlocale() with a category corresponding to the category of item (see ) or the category LC_ALL, or by subsequent calls to uselocale() which change the category corresponding to the category of item." ptsname: P1712 L54754 Add a new paragraph to the RETURN VALUE section: "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to ptsname()." ptsname: P1712 L54760 Change "The value returned may point to a static data area that is overwritten by each call to ptsname()." to "None" readdir: P1744 L55685 Change "The pointer returned by readdir() points to data which may be overwritten by another call to readdir() on the same directory stream. This data is not overwritten by another call to readdir() on a different directory stream." to "The application shall not modify the structure to which the return value of readdir() points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to readdir() on the same directory stream. They shall not be affected by a call to readdir() on a different directory stream." strerror: P1999 L63238 Change "The string pointed to shall not be modified by the application. The string may be overwritten by a subsequent call to strerror(). [CX]The string may be overwritten by a subsequent call to strerror_l() in the same thread.[/CX]" to "The application shall not modify the string returned. [CX]The returned string pointer might be invalidated or[/CX] the string content might be overwritten by a subsequent call to strerror(), [CX]or by a subsequent call to strerror_l() in the same thread[/CX]." strsignal: P2032 L64345 Change "The string pointed to shall not be modified by the application, but may be overwritten by a subsequent call to strsignal() or setlocale()." to "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to strsignal() or setlocale()." ttyname: P2140 L67655 Change "The return value may point to static data whose content is overwritten by each call." to "The application shall not modify the string returned. The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to ttyname()." _____________________________________________________________________________ COMMENT Enhancement Request Number 13 mtk.lists:xxxxxxxxx Bug in XSH (async-cancel-safe text) (rdvk# 1) Tue, 11 Nov 2008 11:14:48 -0500 (16:14 GMT) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In sigwait() RATIONALE > == > After some consideration, threads were allowed to use semaphores > and sem_post() was defined to be async-signal and async-cancel-safe. > == Remove " and async-cancel", so that the resulting text ends up with: "...was defined to be async-signal-safe." This problem seems to date back to the original .1c threads standard. At least, the same rationale appears in POSIX.1-1996 in section B.11.4.3 (Page 527 Line 6994). > And again there seems to be contradictory text in XRAT lines 118498 to > 118499: > > == > IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/6 is applied, adding the > abort() function to the list of async-cancel-safe functions > == Change async-cancel-safe functions to async-signal-safe functions to This one is a mistake in the wording of 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/6. It added abort() to the table of async-signal-safe functions in 2.4.3, but somehow the word "cancel" got into the description of the change instead of "signal". ______________________________________________________________________________ Page: 515 Line: 17842-17845 Section: 2.9.5.4 Problem: Lines 17842 to 17845 of draft 5.1 read as follows: == 2.9.5.4 Async-Cancel Safety The pthread_cancel(), pthread_setcancelstate(), and pthread_setcanceltype() functions are defined to be async-cancel safe. No other functions in this volume of POSIX.1-200x are required to be async-cancel-safe. == But the last sentence above seems to be directly contradicted by lines 62196 to 62197 of the sigwait() spec, which say: == After some consideration, threads were allowed to use semaphores and sem_post() was defined to be async-signal and async-cancel-safe. == And again there seems to be contradictory text in XRAT lines 118498 to 118499: == IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/6 is applied, adding the abort() function to the list of async-cancel-safe functions == Action: Not sure, sorry. The above texts seem to be contradictory, but I'm not sure how the contradiction is to be properly resolved. _____________________________________________________________________________ OBJECTION Enhancement Request Number 14 gwc:xxxxxxxxxxxxx Defect in XSH 2.4.1 (rdvk# 4) [gwc stop and cont signals] Fri, 12 Dec 2008 15:17:48 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 485 Line: 16549 Section: 2.4.1 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The penultimate paragraph of section 2.4.1 states: "When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process, any pending SIGCONT signals for that process shall be discarded. Conversely, when SIGCONT is generated for a process, all pending stop signals for that process shall be discarded. When SIGCONT is generated for a process that is stopped, the process shall be continued, even if the SIGCONT signal is blocked or ignored. If SIGCONT is blocked and not ignored, it shall remain pending until it is either unblocked or a stop signal is generated for the process." This text needs to be updated to take account of threads. The change below is based on the suggestion made by Philip Guenther in austin-group-l 11587. Action: Replace the paragraph with: "When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process or thread, all pending SIGCONT signals for that process or any of the threads within that process shall be discarded. Conversely, when SIGCONT is generated for a process or thread, all pending stop signals for that process or any of the threads within that process shall be discarded. When SIGCONT is generated for a process that is stopped, the process shall be continued, even if the SIGCONT signal is ignored by the process or is blocked by all threads within the process and there are no threads in a call to a sigwait() function selecting SIGCONT. If SIGCONT is blocked by all threads within the process, there are no threads in a call to a sigwait() function selecting SIGCONT, and SIGCONT is not ignored by the process, the SIGCONT signal shall remain pending on the process until it is either unblocked by a thread or a thread calls a sigwait() function selecting SIGCONT, or a stop signal is generated for the process or any of the threads within the process." _____________________________________________________________________________ COMMENT Enhancement Request Number 15 rajani.g.k:xxxxxx Defect in XSH 2.4.3 (rdvk# 6) {GKRFORK012009} Thu, 8 Jan 2009 07:41:10 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We agreed not to send this down the interps track yet. The standard is clear and concerns are being forwarded to the sponsor. A previous interpretation 1003.1c-1995 #37, and also ERN XSHbug2145 have addressed the same issue, but still the problem has remained unresolved. Because of the problems which exist here it has become clear that an application using pthread_atfork(), even if the application itself did not call pthread_atfork(), may have had pthread_atfork() handlers installed by a third party library or the implementation. Therefore calling fork() from an asynchronous signal handler is undefined. Therefore we are removing fork() from the list of async-signal-safe functions. Recommendations for a future revision: A future revision should mandate posix_spawn() and add that to the list of async-signal-safe functions. Remove fork() from the list of async-signal-safe functions. [ 12 Feb 2009 - we had no consensus on the changes for a future revision] _____________________________________________________________________________ Page: 489 Line: 16723 Section: 2.4.3 Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required Section 2.4.3. P489 L16723 Asserts that fork() is async-signal safe. The fork() system interfaces section P882 L29311-29312 asserts that registered fork handlers are executed during the fork. P882 L 29313-29315 asserts that only async-signal safe functions are to be called by pthread_at_fork handlers to provide signal safety for fork(). The rationale section of pthread_atfork() explains the purpose of these functions. As per this section, XSH P1529, L49389-49402, it is possible that multithreaded libraries could be used by single threaded applications. In which case, atfork handlers are essential for the libraries to protect their internal state during fork. As explained further P1530, L49403-49404, pthread_atfork functions are mainly required to acquire/release mutex locks, for protecting the applications/libraries from fork() calls. C-library needs to as well have an atfork handler which acquires all the required locks to protect its memory state across fork(). The acquire/release mutex calls themselves are aync-signal unsafe operations. Use of them makes pthread_atfork handlers async-signal unsafe which in turn makes fork() async-signal unsafe when called by an application which is multi threaded, or which is linked to a library which is multi threaded. Action: Need clarification with respect to 1. Is it correct to list fork as an async-signal safe interface, in a multi threaded scenario? 2. Can the implementation be allowed to not call the atfor handlers, when fork is called from a signal handler? If the atfork handlers are not going to be called when fork is called in the signal handler, then they can not be called, even if fork is called in the newly created child before exec. 3. If only async-signal safe functions are to be called from pthread_atfork handlers, then how will multi-threaded librarie protect themselves by the fork calls, made by single threaded applications linked to them? _____________________________________________________________________________ COMMENT Enhancement Request Number 16 g.clare:xxxxxxxxxxxxx Defect in XSH asctime (rdvk# 1) {gwc asctime rat} Fri, 12 Dec 2008 09:52:56 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 591 Line: 20382 Section: asctime Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The asctime() rationale says: "The standard developers decided to mark the asctime() and asctime_r() functions obsolescent even though they are in the ISO C standard ..." However, asctime_r() is not in ISO C. Action: Change "even though they are in" to "even though asctime() is in" _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 gwc:xxxxxxxxxxxxx Defect in XSH fflush (rdvk# 2) [gwc fflush and ungetc] Fri, 12 Dec 2008 10:23:07 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 844 Line: 28024 Section: fflush Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The descriptions of fflush() and fclose() state: If the file is not already at EOF, and the file is one capable of seeking, the file offset of the underlying open file description shall be adjusted so that the next operation on the open file description deals with the byte after the last one read from or written to the stream being [flushed/closed]. I believe the intention of the statement is that implementations should do the equivalent of lseek(fileno(fp), ftello(fp), SEEK_SET). The point is to prevent data loss when changing the active handle for an open file description to a handle in a different process. Thus if app1 uses stdio to read from stdin, { app1; app2; } < file works as expected without app1 having to do anything special. It just reads from stdin and then closes it (explicitly or implicitly). However, the wording used does not match this intent when ungetc() is involved. Suppose app1 is the type of application that performs read-ahead when it parses its input, and the last thing it did is to call ungetc() before closing standard input. In this case the lseek() above is still the right thing for the implementation to do, so that app2 will read the first byte that was "unwanted" by app1. However, that's not what the statement in the standard requires. The last byte read by app1 was the byte that it passed to ungetc(). The ungetc() doesn't change history; it changes what is returned by the next read on the stream (if any). To match the intent, the wording should be changed so that it simply says the file offset of the underlying open file description is set to the file position of the stream. Another issue is what happens after an ungetc() and fflush() if the active file handle does not change, i.e. there is a subsequent read from the same stream. Should fflush() discard the pushed-back byte or not? Given that the file offset of the underlying open file description has (for the reasons above) been set to the file position of the stream, I think fflush() does have to discard the pushed-back byte. Otherwise that byte will be read twice after the fflush(). Action: Change: the file offset of the underlying open file description shall be adjusted so that the next operation on the open file description deals with the byte after the last one read from or written to the stream being flushed. to: the file offset of the underlying open file description shall be set to the file position of the stream, and any characters pushed back onto the stream by ungetc() or ungetwc() that have not subsequently been read from the stream shall be discarded. At page 805 line 26801 section fclose, change: the file offset of the underlying open file description shall be adjusted so that the next operation on the open file description deals with the byte after the last one read from or written to the stream being closed. to: the file offset of the underlying open file description shall be set to the file position of the stream. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 18 ebb9:xxxxxxx Defect in XSH wcrtomb (rdvk# 5) {ebb.wcrtomb} Tue, 23 Dec 2008 03:34:32 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2195 Line: 69147 Section: wcrtomb Problem: Edition of Specification (Year): 2008 Defect code : 1. Error Per C99, wcrtomb is declared in , not . XBD has the correct listings, only XSH needs adjustment. Action: At line 69147, replace #include with #include _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 gwc:xxxxxxxxxxxxx Defect in XSH 2.9.3 (rdvk# 1) [gwc 2.9.3 EOWNERDEAD] Fri, 9 Jan 2009 15:32:52 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 508 Line: 17536-17542 Section: 2.9.3 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The second paragraph of 2.9.3 states: A thread shall become the owner of a mutex, m, when one of the following occurs: * It returns successfully from pthread_mutex_lock( ) with m as the mutex argument. * It returns successfully from pthread_mutex_trylock( ) with m as the mutex argument. * It returns successfully from pthread_mutex_timedlock( ) with m as the mutex argument. * It returns (successfully or not) from pthread_cond_wait() with m as the mutex argument (except as explicitly indicated otherwise for certain errors). * It returns (successfully or not) from pthread_cond_timedwait() with m as the mutex argument (except as explicitly indicated otherwise for certain errors). There are two problems with this: 1. The first three bullet items do not account for the EOWNERDEAD error, for the named functions and the pthread_mutex_setprioceiling() function, where the mutex is acquired even though the call is not successful. 2. The last two bullet items talk about explicit exceptions for errors which do not acquire the mutex, but there are no such exceptions stated on the pthread_cond_timedwait() page - instead it has a statement for EOWNERDEAD that the mutex is acquired, and a statement in the DESCRIPTION about pthread_cond_timedwait() timeouts: "When such timeouts occur, pthread_cond_timedwait() shall nonetheless release and re-acquire the mutex referenced by mutex." Action: On lines 17536-17538 (first 3 bullet items), change: It returns successfully from [...] with m as the mutex argument. to It calls [...] with m as the mutex argument and the call returns zero or EOWNERDEAD. After line 17538 (3rd bullet item) add a new bullet item: * It calls pthread_mutex_setprioceiling() with m as the mutex argument and the call returns EOWNERDEAD. Replace lines 17539-17542 (last 2 bullet items) with: * It calls pthread_cond_wait() with m as the mutex argument and the call returns zero or certain error numbers (see [xref to pthread_cond_timedwait() page]). * It calls pthread_cond_timedwait() with m as the mutex argument and the call returns zero or certain error numbers (see [xref to pthread_cond_timedwait() page]). _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 gwc:xxxxxxxxxxxxx Defect in XSH fscanf (rdvk# 5) [gwc fscanf return] Fri, 16 Jan 2009 10:55:11 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Nick has progressed a proposal with WG14 which they appear to have accepted as an editorial. We agreed that since its been classified by WG14 as an editorial we can close this item. Change from "If the input ends before the first matching failure or conversion, EOF shall be returned. If any error occurs, EOF shall be returned, [CX]and errno shall be set to indicate the error[/CX]. If a read error occurs, the error indicator for the stream shall be set." to "If the input ends before the first conversion (if any) has completed, and without a matching failure having occurred, EOF shall be returned. If an error occurs before the first conversion (if any) has completed , and without a matching failure having occurred, EOF shall be returned [CX]and errno shall be set to indicate the error[/CX]. If a read error occurs, the error indicator for the stream shall be set." Add to Change History : A change to the second sentence in RETURN VALUE is made to align with expected wording changes in the next revision of the C standard. _____________________________________________________________________________ Page: 934 Line: 31304 Section: fscanf Problem: Edition of Specification (Year): 2008 Defect code : 1. Error In austin-group-l 11809, Vincent Lefvre identified a conflict with the C Standard: ---- begin quote ---- I think there is a contradiction between POSIX.1-2008 and the ISO C standard concerning fscanf when an input failure occurs after the first conversion. The ISO C standard (at least N1124 and N1336) says: 7.19.6.2 The fscanf function 4 The fscanf function executes each directive of the format in turn. If a directive fails, as detailed below, the function returns. Failures are described as input failures (due to the occurrence of an encoding error or the unavailability of input characters), or matching failures (due to inappropriate input). 16 The fscanf function returns the value of the macro EOF if an input failure occurs before any conversion. Otherwise, the function returns the number of input items assigned, which can be fewer than provided for, or even zero, in the event of an early matching failure. For instance, let us consider n = fscanf (stdin, "%d %d", &x, &y); where an input failure occurs *after* the first %d conversion (and before the second one). According to the C standard, n should be equal to 1 because * the input failure occurred *after* the first conversion, * 1 input item (exactly) has been assigned. However POSIX.1-2008 says (page 934): Upon successful completion, these functions shall return the number of successfully matched and assigned input items; this number can be zero in the event of an early matching failure. If the input ends before the first matching failure or conversion, EOF shall be returned. If any error occurs, EOF shall be returned, and errno shall be set to indicate the error. If a read error occurs, the error indicator for the stream shall be set. I wonder what POSIX really means by "If any error occurs, EOF shall be returned [...]". I suppose this means "input failure" in C (as opposed to "matching failure"). But, as shown above, the C standard does the difference between these two kinds of failure only when the failure occurs before the first conversion (indeed one gets EOF in case of an input failure, and 0 in case of a matching failure). ---- end quote ---- An interpretation should be issued stating that POSIX defers to the C Standard here, and conforming implementations must behave as described in the C Standard. The POSIX text should be corrected in TC1 to remove the conflict. During discussions it emerged that, by a strict reading, the phrase "before any conversion" is ambiguous, although the intention is clear (at least, it is to native English speakers). It was proposed to use the phrase "before the first successful conversion" instead, but this has a couple of problems: 1. If the error occurs before the first conversion, then that conversion never happens and cannot be thought of as "successful". 2. Even if the word "successful" is removed, it is still not clear whether the error has to occur before reading the first byte of input that would be used in the conversion, or if the requirement also applies after at least one such byte has been read but with more bytes needed to finish the conversion. I propose to use "without any successful conversions having been made" instead. Action: Change "If the input ends before the first matching failure or conversion, EOF shall be returned. If any error occurs, EOF shall be returned, [CX]and errno shall be set to indicate the error[/CX]. If a read error occurs, the error indicator for the stream shall be set." to "If the input ends without any successful conversions having been made, and without a matching failure having occurred, EOF shall be returned. If an error occurs without any successful conversions having been made, and without a matching failure having occurred, EOF shall be returned [CX]and errno shall be set to indicate the error[/CX]. If a read error occurs, the error indicator for the stream shall be set." Make the same change to the fwscanf() page (P988 L33162). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 21 gwc:xxxxxxxxxxxxx Defect in XSH pthread_cond_timedwait (rdvk# 2) [gwc pctw timeout] Fri, 9 Jan 2009 15:47:43 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1587 Line: 51027-51034 Section: pthread_cond_timedwait Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required In the description of pthread_cond_timedwait(), a statement about the clock attribute and a paragraph break have been inserted between two closely related sentences. The text should be rearranged in order to reunite the related sentences. Action: In the two paragraphs: The pthread_cond_timedwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. The condition variable shall have a clock attribute which specifies the clock that shall be used to measure the time specified by the abstime argument. When such timeouts occur, pthread_cond_timedwait() shall nonetheless release and re-acquire the mutex referenced by mutex. The pthread_cond_timedwait() function is also a cancellation point. move the sentence beginning "When such timeouts occur" to the end of the first of the paragraphs. _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 gwc:xxxxxxxxxxxxx Defect in XSH pthread_mutex_lock (rdvk# 3) [gwc pmtl return] Fri, 9 Jan 2009 15:53:20 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1639 Line: 52741 Section: pthread_mutex_lock Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The RETURN VALUE section on the pthread_mutex_lock() page states: "The pthread_mutex_trylock() function shall return zero if a lock on the mutex object referenced by mutex is acquired. Otherwise, an error number is returned to indicate the error." This conflicts with the description of the EOWNERDEAD error for pthread_mutex_trylock() which says "The mutex lock shall be acquired by the calling thread". Action: On line 52739 (1st line of RETURN VALUE) change "pthread_mutex_lock() and pthread_mutex_unlock()" to "pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock()" Delete lines 52741-52742 (2nd para of RETURN VALUE). _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 gwc:xxxxxxxxxxxxx Defect in XSH ungetc (rdvk# 4) [gwc ungetc fseeko] Fri, 16 Jan 2009 10:06:49 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2151 Line: 67920 Section: ungetc Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of ungetc() states: "A successful intervening call (with the stream pointed to by stream) to a file-positioning function (fseek(), fsetpos(), or rewind()) shall discard any pushed-back bytes for the stream." This text is taken from the C Standard, but in POSIX there is an additional file-positioning function, fseeko(), which should also be listed. The ungetwc() page has the same problem. Action: Change "(fseek(), fsetpos(), or rewind())" to "(fseek(), [CX]fseeko(),[/CX] fsetpos(), or rewind())" Also make the same change on the ungetwc() page (P2152 L67964). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 24 ebb9:xxxxxxx Defect in XSH strtod (rdvk# 1) {ebb.strtod} Sun, 8 Feb 2009 02:26:13 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2036 Line: 64498 Section: strtod Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The text for strtod refers to an undefined variable name. Action: At line 64498, replace: the value of str with: the value of nptr _____________________________________________________________________________ COMMENT Enhancement Request Number 25 mtk.lists:xxxxxxxxx Defect in XSH timer_getoverrun() (rdvk# 2) {timer_getoverrun} Wed, 11 Feb 2009 00:32:04 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This aardvark request was rejected since time_getoverrun() is only defined if the expiration causes signals to be generated. timer_setoverrun() reports the number of signals not generated because of overruns. When threads are used instead of signals, a thread will be created for each event, independent of whether prior threads handling these events have started or completed. _____________________________________________________________________________ Page: 2114 Line: 66945 Section: timer_getoverrun() Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The discussion of timer overruns in lines 66945 to 66956 is phrased entirely in terms of timer notification via signals (SIGEV_SIGNAL). However, a timer overrun can also occur for for notification via a thread (SIGEV_THREAD), since there may be a delay between the timer expiration and the invocation of the corresponding thread, and in that time, further expirations may occur. Linux, at least, supports timer_getoverrun() in the context of timer notification via a thread, and perhaps other systems also do. I suspect the standard should say something about this, an that it may be an accident of history that it doesn't. Action: After line 66956, add text something like the following: An implementation may also support the use of timer_gettoverrun() for retrieving the overrun count when timer expirations are notified via invocation of a thread (SIGEV_THREAD). In this case, the overrun count reflects the number of extra timer expirations that have occurred between the first timer expiration and the time that the notification thread was invoked. _____________________________________________________________________________ COMMENT Enhancement Request Number 26 ed:xxxxxxxxxxx Defect in XSH posix_openpt (rdvk# 1) {n/a} Mon, 16 Feb 2009 17:57:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Based on the information presented tshall be review group feel that the change is not necessary. _____________________________________________________________________________ Page: 0 Line: 0 Section: posix_openpt Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required I guess a small change to the spec could be made to make implementing pseudo-terminals on various operating systems more simple and more secure: The posix_openpt() is often used in combination with grantpt() and unlockpt(). Many operating systems will create a pseudo-terminal on demand, instead of recycling it. Linux uses /dev/ptmx and a file system called devpts, mounted on /dev/pts. In FreeBSD CURRENT, posix_openpt() is implemented as a system call, which allocates a TTY and exposes its device node in devfs. I haven't seen a single piece of software that calls grantpt() on a file descriptor multiple times, or changes the real UID before calling grantpt(). I guess it would be a lot simpler for operating systems to implement this, if there was some kind of provision that if posix_openpt() already performs the necessary steps to change the owner/group of the pseudo-terminal and performs an action similar to unlockpt(), the grantpt() and unlockpt() functions may be implemented as no-ops. I would almost advise to mark grantpt() and unlockpt() as obsolete, but that would break a lot of stuff, I guess. Right now some operating systems use setuid binaries to change the owner of the pseudo-terminal. By changing the specification as described above, operating systems will never need some `supernatural' function to bypass UNIX permissions to chown()/chmod() a character device they don't own. Action: Change grantpt() and unlockpt() to mention: These functions may have no effect on implementations where similar actions are already performed by posix_openpt(). _____________________________________________________________________________ COMMENT Enhancement Request Number 27 peter:xxxxxxxxx Defect in XSH dlerror (rdvk# 1) {none} Mon, 9 Mar 2009 16:01:28 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: -> Interps track The standard is clear, however concerns are being fwd to the sponsor. Change: The dlerror() function need not be thread-safe. To: It is implementation-defined whether or not the dlerror() function is thread-safe. A thread-safe implementation shall return only errors that occur on the current thread. The APPLICATION USAGE on p730 24555-24560 will need changing Change from: may reside in a static buffer To: resides in a buffer that is either system wide or thread wide that may be overwritten on each call to dlerror() _____________________________________________________________________________ Page: 730 Line: 24539 Section: dlerror Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required The dlerror description can be read in such a way that per-thread dlerror strings are not allowed, see the discussion thread (http://www.opengroup.org/austin/mailarchives/ag/msg15415.html) on the opengroup list for a variety of interpretations. A number of implementations from multiple vendors have thread specific errors, including: HP-UX, GNU/Linux with Glibc, Mac OS X, Tru64 Unix, z/OS. Information on most of these implementations was gathered with a small test program, however z/OS information was provided by its manual page: http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.zos.r10.bpxbd00/dlerror.htm The standard should reflect existing practice and should explicitly allow per-thread errors. Action: Change: The dlerror() function need not be thread-safe. To: The dlerror() function need not be thread-safe, however a thread-safe implementation may return only errors that occur on the current thread. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 gwc:xxxxxxxxxxxxx Defect in XSH aio_fsync (rdvk# 3) [gwc aio_fsync option] Mon, 6 Apr 2009 10:24:42 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 573 Line: 19785 Section: aio_fsync Problem: Edition of Specification (Year): 2008 Defect code : 1. Error In the 2008 revision, functionality associated with the AIO option was moved to Base. However, aio_fsync() provides functionality which is equivalent (although asynchronous) to fsync() and fdatasync(), which are part of the FSC and SIO options, respectively. For consistency, aio_fsync() should have been made optional, with functionality equivalent to fsync() being shaded FSC (or FSC SIO where corresponding text on the fsync() page is shaded SIO), and functionality equivalent to fdatasync() being shaded SIO. Another aspect of the same problem is that aio_fsync() page has unshaded references to the constant O_DSYNC, which is only required to be defined by if the SIO option is supported for compilation. Action: Shade the SYNOPSIS with margin code FSC|SIO. At line 19788 change: The aio_fsync() function shall asynchronously force all I/O operations associated with the file indicated by the file descriptor aio_fildes member of the aiocb structure referenced by the aiocbp argument and queued at the time of the call to aio_fsync() to the synchronized I/O completion state. to: The aio_fsync() function shall asynchronously perform a file synchronization operation, as specified by the op argument, for I/O operations associated with the file indicated by the file descriptor aio_fildes member of the aiocb structure referenced by the aiocbp argument and queued at the time of the call to aio_fsync(). At line 19793 add SIO shading to: If op is O_DSYNC, all currently queued I/O operations shall be completed as if by a call to fdatasync(); that is, as defined for synchronized I/O data integrity completion. At line 19794 add FSC shading to: If op is O_SYNC, all currently queued I/O operations shall be completed as if by a call to fsync(); and add FSC SIO shading to: that is, as defined for synchronized I/O file integrity completion. At line 19797 change: operation queued by aio_fsync() fails, then, as for fsync() and fdatasync(), outstanding I/O operations are not guaranteed to have been completed. to: operation queued by aio_fsync() fails, then outstanding I/O operations are not guaranteed to have been completed. At line 19825 add SIO shading to: [EINVAL] This implementation does not support synchronized I/O for this file. and add another EINVAL error after it, shaded FSC: [EINVAL] The aio_fildes member of the aiocb structure refers to a file on which an fsync() operation is not possible. At line 19826 change: [EINVAL] A value of op other than O_DSYNC or O_SYNC was specified. to: [EINVAL] A value of op other than O_DSYNC or O_SYNC was specified, or O_DSYNC was specified and the implementation does not provide runtime support for the Synchronized Input and Output option, or O_SYNC was specified and the implementation does not provide runtime support for the File Synchronization option. At line 19829 change: asynchronous fsync() operation to asynchronous operation Cross-volume change to XBD... page 220 line 7234 section aio.h, add FSC|SIO shading to the declaration of aio_fsync(). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 gwc:xxxxxxxxxxxxx Defect in XSH dlopen (rdvk# 2) [gwc dlopen return on success] Wed, 8 Apr 2009 09:43:15 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 733 Line: 24663 Section: dlopen Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The RETURN VALUE section on the dlopen() page does not state what the function returns on success, only on failure. Action: Insert "Upon successful completion, dlopen() shall return a handle for the executable object file specified by the file argument." before "If file cannot be found, ..." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 30 gwc:xxxxxxxxxxxxx Defect in XSH dlsym (rdvk# 1) [gwc dlsym return on success] Wed, 8 Apr 2009 09:43:51 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 735 Line: 24705 Section: dlsym Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The RETURN VALUE section on the dlsym() page does not state what the function returns on success, only on failure. Action: Insert "Upon successful completion, dlsym() shall return the address of the named symbol." before "If handle does not refer ..." _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 gwc:xxxxxxxxxxxxx Defect in XSH 2.4.3 (rdvk# 1) [gwc pthread_self and kill] Tue, 21 Apr 2009 09:52:25 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 489 Line: 16722 Section: 2.4.3 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of raise() says that it is equivalent to calling pthread_kill(pthread_self(), sig) Since raise() is async-signal-safe, this equivalence implies that pthread_self() and pthread_kill() must also be async-signal-safe, but they are not in the list of async-signal-safe functions. Action: Add pthread_self() and pthread_kill() to the list of async-signal-safe functions. _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 gwc:xxxxxxxxxxxxx Defect in XSH 2.4.3 (rdvk# 2) [gwc pthread_sigmask safety] Fri, 17 Apr 2009 13:27:45 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 489 Line: 16722 Section: 2.4.3 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of pthread_sigmask() says: The function shall be equivalent to sigprocmask(), without the restriction that the call be made in a single-threaded process. Since sigprocmask() is async-signal-safe, this equivalence implies that pthread_sigmask() is also async-signal-safe. However, it is not listed as such in 2.4.3. Action: Add pthread_sigmask() to the list of async-signal-safe functions. _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 gwc:xxxxxxxxxxxxx Defect in XSH mktime (rdvk# 2) [gwc mktime EOVERFLOW] Mon, 27 Apr 2009 10:00:06 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1303 Line: 42798,42800 Section: mktime Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The mktime() EOVERFLOW error is a "may" fail, but it should be "shall" fail. (I.e. it should be "if occurs" not "if detected"). Action: On line 42798 remove the word "may" from "shall return the value (time_t)-1 [CX]and may set errno to indicate the error[/CX]." On line 42800 change "The mktime() function may fail if" to "The mktime() function shall fail if" _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 gwc:xxxxxxxxxxxxx Defect in XSH strtod (rdvk# 1) [gwc errno change on success] Mon, 27 Apr 2009 12:33:07 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2036 Line: 64500 Section: strtod Problem: Edition of Specification (Year): 2008 Defect code : 1. Error C99 says (7.5 paragraph 3) "The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard." This implies that for all functions in C99 where the description documents the use of errno, the function can only set errno as per the description - it cannot change errno on success (unless its description says it can). For some of these functions, POSIX has CX shading on the statement that the function does not change errno on success. This text should not have CX shading. Affected functions are: strtod(), strtof(), strtold(), strtol(), strtoll(), strtoul(), strtoull(), wcstod(), wcstof(), wcstold(), wcstol(), wcstoll(), wcstoul(), wcstoull(). There are also some functions for which POSIX omits a statement that it does not change errno on success. Affected functions are: fgetpos(), fsetpos(), ftell(), fgetwc(), fputwc(), signal(), mbrlen(), mbrtowc(), wcrtomb(), mbsrtowcs(), wcsrtombs(). (Note that, by a strict reading of C99, all the byte I/O and wide I/O functions are also affected. However, this matter has been raised with the C committee and it appears likely that a change will be made in C1x. Therefore I have not included changes for those functions.) Action: Remove the CX shading from "The strtod() function shall not change the setting of errno if successful. Since 0 is returned on error and is also a valid return on success, an application wishing to check for error situations should set errno to 0, then call strtod(), strtof(), or strtold(), then check errno." and remove the CX shading from similar text at page 2044 line 64780 section strtol page 2049 line 64884 section strtoul page 2224 line 69996 section wcstod page 2231 line 70204 section wcstol page 2238 line 70365 section wcstoul (In each case it is the entire CX shaded block that should be unshaded.) Also for strtod(), strtol(), strtoul(), wcstod(), and wcstoul() change the first sentence of the affected text to match wcstol(): "These functions shall not change the setting of errno if successful." At page 850 line 28241 section fgetpos page 854 line 28343 section fgetwc page 910 line 30406 section fputwc page 940 line 31503 section fsetpos page 1272 line 41808 section mbrlen page 1274 line 41871 section mbrtowc page 1277 line 41989 section mbsrtowcs page 1937 line 61644 section signal page 2195 line 69168 section wcrtomb page 2219 line 69823 section wcsrtombs add a new paragraph (substituting the relevant function name for "funcname") at the end of the DESCRIPTION: "The funcname() function shall not change the setting of errno if successful. At page 956 line 32041 section ftell change "[CX]The ftello() function shall be equivalent to ftell(), except that the return value is of type off_t.[/CX]" to "The ftell() function shall not change the setting of errno if successful. [CX]The ftello() function shall be equivalent to ftell(), except that the return value is of type off_t and the ftello() function may change the setting of errno if successful.[/CX]" _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 dcragun:xxxxxxxxx Defect in XSH time() (rdvk# 3) {time() missing error} Sat, 25 Apr 2009 06:36:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to clock_gettime Page 668 after line 22669 The clock_gettime() function shall fail if: [EOVERFLOW] The current value of time will not fit in an object of type time_t." On the time() page: Add a may fail case. Change: "No errors are defined." on P2107, L66673 in the ERRORS sections to: "The time() function may fail if: [EOVERFLOW] The current value of time will not fit in an object of type time_t." Add to RATIONALE on time() On some systems the time() function is implemented using a system call that does not return an error condition in addition to the return value. In this case it is impossible to differentiate between a valid and invalid return value and hence overflow conditions cannot be detected. _____________________________________________________________________________ Page: 2107 Line: 66673 Section: time() Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission Many systems today have 32-bit time_t types. At some point in the future, these systems will be unable to represent seconds since the Epoch (the return value from time()) in an object of type time_t, but the ERRORS section says "No errors are defined." As with other interfaces where returned information might not fit into the space reserved for the return value, time() should specify that when this happens, (time_t)-1 will be returned and errno will be set to EOVERFLOW. Action: Send this issue down the interpretations track: the standard is silent on this issue; concerns have been forwarded to the sponsor. Change: "shall return the value of time." on P2107, L66670 in the RETURN VALUE section to: "shall return the value of time without changing the value of errno." Change: "No errors are defined." on P2107, L66673 in the ERRORS sections to: "The time() function shall fail if: [EOVERFLOW] The current value of time will not fit in an object of type time_t." Change: "None." on P2108, L66710 in the APPLICATION USAGE section to: "As (time_t)-1 is a permissible return value in a successful situation, an application wishing to check for error conditions should set errno to 0, then call time(), and, if it returns (time_t)-1, check to see if errno is non-zero." _____________________________________________________________________________ COMMENT Enhancement Request Number 36 half:xxxxxxxxxxxxxxxx Bug in XSHd5.1 (rdvk# 3) {8623} Tue, 19 May 2009 15:46:56 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 264 Line: 8623 Section: Problem: The reference to should be . Action: Replace with . _____________________________________________________________________________ COMMENT Enhancement Request Number 37 half:xxxxxxxxxxxxxxxx Defect in XSH (rdvk# 2) {279} Tue, 19 May 2009 16:03:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We agreed to make the change as proposed and also to change the CX Shading block as follows on line 8756-8757 Many of the symbols listed here are not defined by the ISO/IEC 9899: 1999 standard. Such symbols are not shown as CX shaded, except under the heading "Numerical Limits". _____________________________________________________________________________ Page: 279 Line: 0 Section: Problem: Edition of Specification (Year): 2008 Defect code : 1. Error LONG_BIT, WORD_BIT and SSIZE_MAX are missing the CX shading. Action: Add the CX shading to LONG_BIT (pg. 278 lines 9218-9220), WORD_BIT (pg. 279 lines 9260-9262) and SSIZE_MAX (pg. 279 lines 9242-9244). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 msebor:xxxxxxxxx Bug in XSHd5.1 2.9.1 (rdvk# 4) {mblen() not thread-safe} Wed, 20 May 2009 00:22:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ->interps Send this down the interpretations track with the normal boilerplate for "standard is clear; standard is wrong". Concerns are being forwarded to the sponsor. Proposed changes for a future revision/ Add mblen(), mbstowcs(), and mbtowc() in subclause 2.9.1 in alphabetic order to the list of functions that need not be thread-safe in the table on P507, L17490-17510. Change the list of functions that need not be thread-safe if called with a NULL ps argument in subclause 2.9.1 on P507, L17512 from: "wcrtomb() and wcsrtombs()" to: "mbrlen(), mbrtowc(), mbsnrtowcs(), mbsrtowcs(), wcrtomb(), wcsnrtombs(), and wcsrtombs()" Add a new paragraph to the mblen() DESCRIPTION after P1270, L41765: "The mblen() function need not be thread-safe." with CX shading. Add a new paragraph to the mbrlen() DESCRIPTION after P1272, L41808: "The mbrlen() function need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbrtowc() DESCRIPTION after P1274, L41871: "The mbrtowc() function need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbsnrtowcs() and mbsrtowcs() DESCRIPTION after P1277, L41989: "The mbsnrtowcs() and mbsrtowcs() functions need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbtowc() DESCRIPTION after P1281, L42094: "The mbtowc() function need not be thread-safe." with CX shading. Change: "The wcsrtombs() function" in the DESCRIPTION of wcsnrtombs() and wcsrtombs() on P2219, L69818 to: "The wcsnrtombs() and wcsrtombs() functions" keeping the CX shading. Remove wcstombs() from the current table of non thread safe functions On page 2235 remove line 70283 "need not be thread-safe" _____________________________________________________________________________ Page: 507 Line: 17490 Section: 2.9.1 Problem: mblen() and mbtowc() are expected to maintain an internal shift state from one call to the next. However, neither function is listed in 2.9.1, Thread-Safety, among functions that are not required to be thread-safe. Thus, the specification effectively requires that each function maintain a thread-local copy of the state. However, at least two recent quality implementations maintain a per-process state instead, and thus are not thread-safe. A discussion on austin-group-l indicates that the named functions are not, in fact, intended to be thread-safe. Action: Add mblen() and mbtowc() functions that maintain an internal state to the list of functions that are not required to be thread safe, in 2.9.1, Thread-Safety. _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 ebb9:xxxxxxx Defect in XSH memchr (rdvk# 1) {ebb.memchr} Wed, 27 May 2009 13:58:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In the DESCRIPTION remove "of the object" from The memchr( ) function shall locate the first occurrence of c (converted to an unsigned char) in the initial n bytes (each interpreted as unsigned char) of the object pointed to by s. In the RETURN VALUE section The memchr( ) function shall return a pointer to the located byte, or a null pointer if the byte does not occur in the object. to The memchr( ) function shall return a pointer to the located byte, or a null pointer if the byte is not found. Also Nick will let the C committee know about the issue Add to DESCRIPTION Implementations shall behave as if they read the memory byte by byte from the beginning of the bytes pointed to by s and stop at the first occurrence of c (if it is found in the initial n bytes). _____________________________________________________________________________ Page: 1284 Line: 42163 Section: memchr Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission Traditional implementations of memchr process the input in ascending order. This has the advantage that when the object size of s is not known, but c occurs within the object, the caller can pass a value of n that is larger than the actual object size without dereferencing inaccessible memory. However, while the standard (and C99) is explicit that it is permissible to pass n smaller than the object size of s, it is silent on whether passing a larger n is well-defined. In contrast, consider the wording for fprintf when dealing with the %.*s specifier, from line 29938: "If the precision is not specified or is greater than the size of the array, the application shall ensure that the array contains a null byte." Many implementations of the *printf family use memchr to implement this statement; for example, http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/vasnprintf.c?id=d4ca645#n197 However, if memchr does not have any strict requirement on evaluation order, then this invokes undefined behavior. For example, here is a bug report showing what happens when memchr does not have the traditional behavior, but dereferences memory that fits with the n argument to memchr but not within the actual array passed to printf: http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml Likewise, application writers have noticed that it is possible to write faster code for finding a NUL byte, if one is present within a bounded length, by using memchr rather than strnlen, since the former has fewer conditionals (bounds check and search for NUL) than the latter (bounds check, search for NUL, and search for c). For example: http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/strnlen1.c?id=d4ca645 But again, this usage is rendered unsafe unless memchr is specified to behave like strnlen and not dereference past the match. Action: At the end of the paragraph at line 42164, append a sentence with CX shading: If n is larger than the object pointed to by s, the application shall ensure that an instance of c occurs within the object. Change the rationale at line 42174 from: None. to: Although C99 is silent on the behavior of memchr when s points to an array smaller than n bytes, this specification requires memchr to behave as if it accesses bytes in ascending order, thus making memchr(s,0,n) safe to use as a faster alternative to strnlen(s,n) when determining if the end of a null-terminated string occurs within n bytes. According to ebb9:xxxxxxx on 5/27/2009 6:58 AM: > Likewise, application writers have noticed that it is possible to > write faster code for finding a NUL byte, if one is present within a > bounded length, by using memchr rather than strnlen, since the former > has fewer conditionals (bounds check and search for NUL) than the > latter (bounds check, search for NUL, and search for c). Correction - I meant to compare memchr(s,c,n) to strchr(s,c) where c is known to occur in s; strchr requires a search for c and for NUL, and the search for two bytes in parallel is typically more expensive than a bounds check and single search. There is no strnchr, so nothing is standardized that performs all three of bounds check, search for NUL, and search for c at once. (That behavior is also useful--for example, gnulib provides a function memchr2--but it can wait for another day to be standardized). But one point remains - many applications use memchr(s,0,n) rather than strnlen(s,n) because strnlen was not present in earlier standards. So this aardvark is still useful in standardizing this relationship. > Change the rationale at line 42174 from: > > None. > > to: > > Although C99 is silent on the behavior of memchr when s points to an > array smaller than n bytes, this specification requires memchr to > behave as if it accesses bytes in ascending order, thus making > memchr(s,0,n) safe to use as a faster alternative to strnlen(s,n) when > determining if the end of a null-terminated string occurs within n > bytes. Therefore, we may want to strike the word 'faster' in this proposed rationale. _____________________________________________________________________________ COMMENT Enhancement Request Number 40 nick:xxxxxxxxxx Defect in XSH fmemopen (rdvk# 1) {NMS-24731-2-align} Thu, 4 Jun 2009 02:48:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Withdrawn by submitter _____________________________________________________________________________ Page: 866 Line: 28754 Section: fmemopen Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required During the process of balloting the C language Technical Report on dynamic memory functions (TR 24731-2) a comment was recevied from Canada: Because this feature is only useful when the stream is opened for reading or updating" says that the feature is useful for reading. Given the buffer contents are not defined at that point, we need an example where reading would be useful (Ex. A bad random number generator seed). They also pointed out: "fmemopen call may fail if the mode argument does not include a +" contradicts the reading aspect of the Because this feature is only useful when the stream is opened for reading or updating" statement given + means update. They further suggested changing the text: Because this feature is only useful when the stream is opened for updating" The C committee is proposing to accept this change, but want to know if this should then be marked as a POSIX extension in some way (just as POSIX uses CX shading). Action: Change Because this feature is only useful when the stream is opened for reading or updating" to Because this feature is only useful when the stream is opened for updating" _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 gwc:xxxxxxxxxxxxx Defect in XSH 2.3 ENOTSUP (rdvk# 1) [gwc ENOTSUP desc] Tue, 9 Jun 2009 09:40:33 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 482 Line: 16430 Section: 2.3 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The general ENOTSUP description in 2.3 does not match its uses on individual function pages. For example clock_nanosleep() uses it to indicate a clock ID is not supported; mmap() to indicate certain flags are not supported; mprotect() to indicate an access combination is not supported; and numerous pthread_*set*() functions use it to indicate that a requested value is not supported. Also most uses of ENOTSUP do not have XSI shading, so describing it in terms of an XSI feature group is wrong. Action: Change "The implementation does not support this feature of the Realtime Option Group." to "The implementation does not support the requested feature or value." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 42 nick:xxxxxxxxxx Defect in XSH sem_init (rdvk# 3) {nms-sem-base} Tue, 16 Jun 2009 00:45:23 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1818 Line: 58049 Section: sem_init Problem: Edition of Specification (Year): 2008 Defect code : 1. Error At Issue 7, we moved the SEM option to base. However, the Application Usage for sem_init() states "The sem_init( ) function is part of the Semaphores option and need not be available on all implementations." This is no longer true. The same holds for other semaphore functions: sem_close(), sem_destroy(), sem_getvalue(), sem_open(),sem_post(), sem_trywait(), sem_unlink(), and sem_wait() [this last is a pointer page to sem_trywait()]. Note that sem_timedwait() does not suffer from the problem. Action: At the following page/lines, remove the words "The xx() function is part of the Semaphores option and need not be provided on all implementations." Page Line 1812 57909 1814 57950 1816 57992 1818 58049 1822 58156 1823 58223 1828 58405 1830 58462 In all cases except page 1828, line 58405, replace the Application Usage with "None." (The exception, for sem_trywait() and sem_wait(), has a second paragraph in App Usage which will now stand alone). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 43 nick:xxxxxxxxxx Defect in XSH setenv (rdvk# 2) {nms-setenv-seealso} Tue, 16 Jun 2009 19:10:23 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1858 Line: 59385 Section: setenv Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The See Also for setenv does not mention putenv, (though putenv() has a link to setenv()). These two functions are clearly have a relationship, and a cross reference between them would be helpful. Action: Add "putenv()" to the See Also on page 1858, line 59385. --last bug number 43