Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001741 [Issue 8 drafts] System Interfaces Objection Error 2023-05-31 17:13 2023-08-08 11:29
Reporter ajosey View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied   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 Note: 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 doc file icon ISO_IEC CD 9945 Collated Comments.doc [^] (26,476 bytes) 2023-05-31 17:13

- Relationships

-  Notes
(0006393)
geoffclare (manager)
2023-07-18 16:18
edited on: 2023-07-18 16:22

 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.
(0006395)
geoffclare (manager)
2023-07-20 16:19

 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.

The category argument specifies the locale category to be queried. If the value is LC_ALL or is not a supported locale category value (see [xref to setlocale()]), getlocalename_l() shall fail.
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.

If category is LC_ALL, the getlocalename_l() function shall return a string that encodes the locale settings for all locale categories of the locale object locobj, or of the global locale if locobj is the special locale object LC_GLOBAL_LOCALE, in the same form as is returned by setlocale(). The string returned is such that a subsequent call to setlocale(), from the same process, with a pointer to that string as locale and the LC_ALL category shall set the global locale to the same locale for each category as was present in the queried object.

If the value of the category argument is neither LC_ALL nor a supported locale category value (see [xref to setlocale()]), getlocalename_l() shall fail.


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.
(0006419)
geoffclare (manager)
2023-08-08 11:29

 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".

- Issue History
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 => Note: 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker