View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001741 | Issue 8 drafts | System Interfaces | public | 2023-05-31 17:13 | 2024-06-11 09:12 |
| Reporter | ajosey | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Product Version | Draft 3 | ||||
| Name | Andrew Josey | ||||
| Organization | |||||
| User Reference | ISO/US-003 | ||||
| Section | 3 | ||||
| Page Number | 1137 | ||||
| Line Number | 38955-38956 | ||||
| Final Accepted Text | 0001741:0006395 | ||||
| Summary | 0001741: getlocalename_l (ISO/US-003) | ||||
| Description | In Volume 2, Chapter 3, the Description for getlocalename_l specifies that using LC_ALL as the category argument for a call shall result in the call being not successful. This restriction in functionality leaves application developers without a portable way to record, into a string usable with setlocale (with LC_ALL), the “name” of the locale represented by the locale object. In particular, “composite” or “mixed” locales using a different locale definition for at least one category have such “names” formed by the implementation, but the format is not uniform across implementations. The C++ standard library presents a std::locale type with interfaces that can produce such mixed locales in a thread-safe manner. It also includes a std::locale::global function that requires setlocale interaction with such a mixed std::locale. C++ standard library implementations currently suffer in terms of quality or portability from a lack of a C-level, standardized, thread-safe locale interface that will produce a “name” for such mixed locales. As POSIX provides thread-safe locales as an extension to C, the missing functionality seems to be within the scope of POSIX to provide. | ||||
| Desired Action | Remove the specification that using LC_ALL results in a call being not successful. Specify that using LC_ALL results in “a string which encodes the locale name(s) for all of the individual categories, consistent with setlocale”. Specify that using LC_ALL for the category returns a string that may be invalidated or overwritten by a subsequent call in the same thread with LC_ALL. Update the rationale; an example use case for LC_ALL is application portability in recording the “international environment” even in the face of extensions such as the introduction of extra categories such as LC_TELEPHONE. | ||||
| Tags | applied_after_i8d3, issue8 | ||||
| Attached Files | |||||
|
|
Since the specification for getlocalename_l() in the draft was based on the __getlocalename_l() function in Solaris 11.4, I checked how that function behaves when called with LC_ALL. It does actually do what is being asked for here, i.e. it returns the same string that setlocale() would return for the equivalent global locale setting:$ LC_TIME=en_GB LC_MONETARY=en_US ./a.out __getlocalename_l: /C/C/en_GB/C/en_US/C setlocale : /C/C/en_GB/C/en_US/C So I am in favour of making a normative text change along the lines suggested. However, I am dubious about the suggested rationale addition of a use case in recording the information, as there is no requirement that the string contains printable characters, and storing it for use in a later setlocale() call (by another process) would be fragile, as a future OS upgrade could change the string format. A possible genuine use case might be an application that has a locale object and wants to duplicate its locale settings in the global locale. |
|
|
Change:The getlocalename_l() function shall return the locale name for the given locale category of the locale object locobj, or of the global locale if locobj is the special locale object LC_GLOBAL_LOCALE.to: If category is not LC_ALL, the getlocalename_l() function shall return the locale name for the given locale category of the locale object locobj, or of the global locale if locobj is the special locale object LC_GLOBAL_LOCALE. Change APPLICATION USAGE from "None" to: In addition to the caveats regarding validity of the returned string pointer in RETURN VALUE, the content of the string returned when category is LC_ALL is only required to be valid for the life of the process, so is not intended for storage or sharing between processes. As the internal format of the string is implementation-specific, there is nothing preventing a subsequent run of an application from being presented a different format, for example if the implementation is updated. |
|
|
When applying this bug I noticed that the RETURN VALUE section still said that a successful call "shall return a pointer to a string containing the locale name". I have changed it to just "shall return a pointer to a string". |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-05-31 17:13 | ajosey | New Issue | |
| 2023-05-31 17:13 | ajosey | File Added: ISO_IEC CD 9945 Collated Comments.doc | |
| 2023-05-31 17:13 | ajosey | Name | => Andrew Josey |
| 2023-05-31 17:13 | ajosey | User Reference | => ISO/US-003 |
| 2023-05-31 17:13 | ajosey | Section | => 3 |
| 2023-05-31 17:13 | ajosey | Page Number | => na |
| 2023-05-31 17:13 | ajosey | Line Number | => na |
| 2023-07-17 23:17 | Don Cragun | Page Number | na => 1137 |
| 2023-07-17 23:17 | Don Cragun | Line Number | na => 38955-38956 |
| 2023-07-18 16:18 | geoffclare | Note Added: 0006393 | |
| 2023-07-18 16:22 | geoffclare | Note Edited: 0006393 | |
| 2023-07-20 16:19 | geoffclare | Note Added: 0006395 | |
| 2023-07-20 16:20 | geoffclare | Final Accepted Text | => 0001741:0006395 |
| 2023-07-20 16:20 | geoffclare | Status | New => Resolved |
| 2023-07-20 16:20 | geoffclare | Resolution | Open => Accepted As Marked |
| 2023-07-20 16:20 | geoffclare | Tag Attached: issue8 | |
| 2023-08-08 11:29 | geoffclare | Note Added: 0006419 | |
| 2023-08-08 11:29 | geoffclare | Status | Resolved => Applied |
| 2023-08-08 11:29 | geoffclare | Tag Attached: applied_after_i8d3 | |
| 2024-06-11 09:12 | agadmin | Status | Applied => Closed |
