Extended API Set Part 4 Final Dispositions Page 1 of 1 Submitted by Andrew Josey, The Open Group. April 12, 2006 This is the final dispositions. ERNs 5 and 14 were updated after the further resolution meeting. Aardvark Summary Table ______________________ ERN 1 Accept ERN 2 Accept as marked ERN 3 Accept ERN 4 Accept ERN 5 Accept as marked ** ERN 6 Accept ERN 7 Accept ERN 8 Accept ERN 9 Accept ERN 10 Accept as marked ERN 11 Accept as marked ERN 12 Accept as marked ERN 13 Accept ERN 14 Accept as marked ** _____________________________________________________________________________ COMMENT Enhancement Request Number 1 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 2) {DWC-API4-1} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1 Line: 6-7 Section: 1.1 Problem: The current scope describes what duplocale(), freelocale(), newlocale(), and uselocale() do. There is nothing in the bulk of the functions in this proposal (the *_l() functions) that have anything to do with threads. The *_l() functions allow an application (single- or multi-threaded) to use multiple locales concurrently. Action: Change P1, L6-7 from: The scope of this set of extensions has been to consider a set of interfaces drawn from existing implementations that provide a thread-aware locale extension. to: This proposal adds a set of interfaces that allow applications to use multiple locales concurrently and allow multi-threaded applications to use a different base locale in each thread. _____________________________________________________________________________ COMMENT Enhancement Request Number 2 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 3) {DWC-API4-2} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change section 1.2 from: No decision has been made on whether these interfaces will be added to a future technical standard of The Open Group, how these interfaces would announce themselves in the namespace, or whether related interfaces should be merged with existing pages. This technical standard is being forwarded to the Austin Group for consideration as input to the revision of the Base Specifications, Issue 6. To: This technical standard is being forwarded to the Austin Group for consideration as input to the revision of the Base Specifications, Issue 6. It is recommended that these functions be integrated as follows: - When an implementation claims support of this option all functions except uselocale() shall be provided. - If an implementation claims to support both the new option and the Threads option, it must also provide uselocale(). _____________________________________________________________________________ Page: 1 Line: 9-13 Section: 1.2 Problem: I believe that we need to specify how we believe this should be handled in the revision. Action: I am open to other suggestions, but as a starting point I suggest that we specify that all of the functions in this proposal are to be specified as a new option. I suggest all of these functions, except uselocale(), must be provided when an implementation claims to support the new option. If an implementation claims to support both the new option and the Threads option, it must also provide uselocale(). Other changes below specify changes to the uselocale() man page corresponding to this issue. _____________________________________________________________________________ COMMENT Enhancement Request Number 3 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 4) {DWC-API4-3} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 15-27 Section: 2 Problem: See also my comment DWC-API4-1. Only uselocale() in this proposal is directly related to threads. All of the other interfaces can be used to allow any thread (even the main thread in a single-threaded application) to simultaneously use multiple locales. Calling this the Thread-aware Locale Interfaces option is strange. Furthermore, this is an option; not an option group. Action: Change P3, L15-16 to something like: It is proposed that these additions comprise a new option, called the Multiple Concurrent Locales option. Globally change "THL" in this draft to "MCL". Globally change "Thread-aware Locale Interfaces" and "Thread-aware Locale" (without " Interfaces") in this draft to "Multiple Concurrent Locales". _____________________________________________________________________________ COMMENT Enhancement Request Number 4 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 5) {DWC-API4-4} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 18 Section: 2.1 Problem: See also my comment DWC-API4-3. The description of the THL margin code here only applies to changes in XBD. This draft also makes changes to XSH and uses the THL margin code and shading in XSH, but does not specify addition of this new code in that volume. Action: Unless this change goes into a file that is shared in XBD, XCU, XSH, and XRAT, add corresponding changes for XSH section 1.8.1. If it is shared between all of the volumes, add a note saying so in the Notes To Reviewers on P3, L21-22. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 6) {DWC-API4-5} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a new feature announcement macro to by making the following changes: Add before P4, L89: The following will be added with an MCL margin marker and shaded. _POSIX_MULTIPLE_LOCALES The implementation supports the Multiple Concurrent Locales option. If this symbol is defined in , it shall be defined to be -1, 0, or 200ymmL. The value of this symbol reported by sysconf() shall either be -1 or 200ymmL. The following will be added to the list of symbolic constants that shall be defined for sysconf() with no margin marker nor shading. _SC_MULTIPLE_LOCALES _____________________________________________________________________________ Page: 5 Line: 89 Section: 2.2 Problem: See also my comment DWC-API4-3. If that comment is not accepted, change the reference to "MCL" below to "THL". Since we are introducing a new option, we need to have a way to determine if the option is present. Action: Add a new feature announcement macro to by making the following changes: Add before P4, L89: The following will be added with an MCL margin marker and shaded. _XOPEN_MULTIPLE_LOCALES The implementation supports the Multiple Concurrent Locales option. If this symbol is defined in , it shall be defined to be -1, 0, or 200ymmL. The value of this symbol reported by sysconf() shall either be -1 or 200ymmL. The following will be added to the list of symbolic constants that shall be defined for sysconf() with no margin marker nor shading. _SC_MULTIPLE_LOCALES _____________________________________________________________________________ EDITORIAL Enhancement Request Number 6 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 7) {DWC-API4-6} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 7 Line: 124 Section: 3.1 Problem: Stating that these functions work on "objects" is too generic. Action: Change "objects" on P7, L124 to "locale objects". _____________________________________________________________________________ COMMENT Enhancement Request Number 7 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 8) {DWC-API4-7} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 9 Line: 137-140 Section: duplocale() Problem: I don't think so. (At least not with this name.) I might be willing to accept adding LC_NULL which could be used in this case and a few others. Action: Delete the Notes to Reviewers on P9, L137-140. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 9) {DWC-API4-8} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 9,... Line: 182,... Section: duplocale() Problem: The duplocale() SEE ALSO list doesn't need to list itself. Action: Change "duplocale() on P9, L182 to "newlocale()". _____________________________________________________________________________ COMMENT Enhancement Request Number 9 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 10) {DWC-API4-9} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 10 Line: 194-195 Section: freelocale() Problem: The you use a pointer freed by free() the results are undefined, not unspecified. The results of using a pointer freed by freelocale() should be described the same way. Furthermore, uselocale() isn't the only function that can create a locale object that can be freed by freelocale(), and uselocale() isn't the only function that uses locale_t objects. Action: Change P10, L194-195 from: If a locale object is passed to freelocale() while it is still in used by a thread that has called uselocale(), the behavior is unspecified. to: Any use of a locale object that has been freed results in undefined behavior. _____________________________________________________________________________ COMMENT Enhancement Request Number 10 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 11) {DWC-API4-10} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This applies to page 15 line 326 uselocale() Change the margin marking on P15, L326 from "THL" to "MCL&THR". _____________________________________________________________________________ Page: 12 Line: 229 Section: newlocale() Problem: See also my comment DWC-API4-3. If that comment is not accepted, change the reference to "MCL" below to "THL". Unless the Threads option becomes part of the base requirements in the next revision, implementing newlocale() is meaningless unless the Threads option is also implemented. Action: Change the margin marking on P12, L229 from "THL" to "MCL&THR". _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 12) {DWC-API4-11} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Page 12 line 234-236 Change from The newlocale( ) function shall create a new locale object or modify an existing one. If the base argument is (locale_t)0 a new object shall be created. Otherwise the locale object pointed to by base shall be modified. To: The newlocale( ) function shall create a new locale object or modify an existing one. If the base argument is (locale_t)0 a new locale object shall be created. It it unspecified whether the locale object pointed to by base shall be modified or freed and a new locale object created. Delete line 265-266 If the base argument is not (locale_t)0 , it is unspecified whether the return value is the same as the base argument. Add before the "If.." in 257 Applications shall ensure that they stop using /base/ as a locale object before calling newlocale(). _____________________________________________________________________________ Page: 12 Line: 256-257,265-266 Section: newlocale() Problem: P12, L235-236 says that if base is not (locale_t)0, the locale pointed to by base shall be modified. Why do L256-257 and L265-266 say that the contents of base and the return value are unspecified if the call succeeds. Since this draft is silent about the type underlying locale_t, there is no way to compare the return value to base to determine whether or not base needs to be freed. Therefore, there allows an inherent memory leak that the caller has no way of plugging. Action: Delete the first sentence from P14, L256-257. Change: it is unspecified whether the return value is the same as the base argument on P12, L265-266 to: the return value shall be the same as the base argument _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 13) {DWC-API4-12} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change line 330 from The uselocale( ) function shall set the new locale for the current thread to the locale represented by newloc. To: The uselocale( ) function shall set the current locale for the current thread to the locale represented by newloc. Change line 336-337 from Once the uselocale( ) function has been called to install a thread-local locale the behavior of every interface using locale data shall be affected for the calling thread. The locale setting for other threads shall remain unchanged. To: Once the uselocale( ) function has been called to install a thread-local locale the behavior of every interface using data from the current locale shall be affected for the calling thread. The current locale for other threads shall remain unchanged. Remove 339-341 If the locale object pointed to by newloc is modified by a call to the newlocale( ) function while it is still being used in any thread, the behavior of those threads accessing the locale date is unspecified. _____________________________________________________________________________ Page: 15 Line: 340-341 Section: uselocale() Problem: I don't know how an application uses a locale's date, but I think the important thing here is the locale object. Action: Change "accessing the locale date" on P15, L340 to "accessing that locale object". _____________________________________________________________________________ COMMENT Enhancement Request Number 13 don.cragun@Sun.COM Bug in ExtAPI_4 (rdvk# 14) {DWC-API4-13} Fri, 10 Mar 2006 15:42:32 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 17 Line: 369-370 Section: 3.2 Problem: See also my comment DWC-API4-1. None of the functions in this section are restricted to multi-threaded applications. Action: Change P17, L369-370 to: 3.2 Alternative locale versions of Existing Interfaces The following functions are similar to existing standard functions. All of them take a locale object argument that specifies an alternative locale to be used instead of the process' or thread's current locale. These pages are to be merged into XSH Chapter 3 in alphabetic order. _____________________________________________________________________________ OBJECTION Enhancement Request Number 14 glen.seeds@cognos.com Bug in ExtAPI_4 strerror (rdvk# 1) {GMS-002} Wed, 1 Mar 2006 20:13:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the NAME section to: strerror, strerror_l, strerror_r -- get error message string Add the following line, shaded and MCL marked, between the current entries for strerror() and strerror_r() in the SYNOPSIS section: MCL char *strerror_l(int errnum, locale_t locale); Add the following paragraph, shaded and MCL marked, in the DESCRIPTION section before the current paragraph that says "The strerror() function shall not change the setting of errno if successful.": MCL The strerror_l() function shall not change the setting of errno MCL if successful. Add the following paragraphs, shaded and MCL marked, before the last paragraph in the DESCRIPTION section: MCL The strerror_l() function shall map the error number in errnum MCL to a locale-dependent error message string in the locale MCL represented by locale and shall return a pointer to it. In XSH strerror() page 1441 in DESCRIPTION change from: "The string pointed to shall not be modified by the application, but may be overwritten by a subsequent call to strerror(), or perror()." To: "The string pointed to shall not be modified by the application. The string may be overwritten by a subsequent call to strerror(), or [CX] perror() [/CX]". Add another sentence. MCL The string may be overwritten by a subsequent call to strerror_l() in the MCL same thread. Add the following paragraph, shaded and MCL marked, to the RETURN VALUE section before the current last paragraph: MCL Upon successful completion, strerror_l() shall return a pointer MCL to the generated message string. If errnum is not a valid MCL error number, errno may be set to EINVAL, but a pointer to a MCL message string shall still be returned. If any other error MCL occurs, errno shall be set to set to indicate the error and a MCL null pointer shall be returned. Add the following to the ERRORS section before the strerror_r() may fail entries with shading and MCL marking on the indicated lines: The strerror_l() function may fail if: MCL [EINVAL] The locale argument is not a valid locale object handle. Add the following paragraph to the RATIONALE section: The strerror_l() function is required to be thread-safe, thereby eliminating the need for an equivalent to the strerror_r() function. _____________________________________________________________________________ Page: 48 Line: 1356 Section: strerror Problem: The functions strerror and strerror_r are locale-dependent, but have no corresponding extensions in this proposal. These are needed for the proposal to be complete. Action: Insert a copy of the definiitons for strerror and strerror_r, with specific sections modified as follows: NAME strerror_l, strerror_rl -- get error message string SYNOPSIS #include char *strerror_l(int errnumc, locale_t locale); TSF int strerror_rl(int errnum, char *strerrbuf, size_t buflenc, locale_t locale); DESCRIPTION The strerror_l( ) function shall map the error number in errnum to a locale-dependent error in the locale represented by *locale* and shall return a pointer to it. The strerror_r( ) function shall map the error number in errnum to a locale-dependent error message string in the locale represented by *locale* and shall return the string in the buffer pointed to by strerrbuf, with length buflen. ERRORS These functions may fail if: [EINVAL] locale is not a valid locale object handle.