A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1220 ====================================================================== Reported By: bhaible Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1220 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section: --- Page Number: --- Line Number: --- Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2018-12-20 13:46 UTC Last Modified: 2020-10-30 18:23 UTC ====================================================================== Summary: Add an API to query the name of a locale category of a locale object ======================================================================
---------------------------------------------------------------------- (0005088) shware_systems (reporter) - 2020-10-30 18:23 https://austingroupbugs.net/view.php?id=1220#c5088 ---------------------------------------------------------------------- No, I understand some are silly enough to implement it that way because the standard allows it and this simplifies the code a tiny bit, but also frequently wastes significant space on redundant string storage when a system has many processes active. Having all categories reference a single string value after a setlocale(LC_ALL) isn't precluded, however. You are correct, for these implementations as they stand, this affects what getlocalename_l(LC_ALL, LC_GLOBAL_LOCALE) can return. The only reliable value is the default "POSIX" required at process startup. I do not see as onerous adding a CX requirement to setlocale() that when LC_ALL is used the value be saved for use by this interface. Similar goes for newlocale() when base is 0 about locale_t data maintaining a reference. This does not force them to change code to make use of it for accessing locale data, but enables this feature to be portable. Other possibilities are ENOSUP as a may fail error or a sysconf() "is this reliable" check for adding it to be robust. Issue History Date Modified Username Field Change ====================================================================== 2018-12-20 13:46 bhaible New Issue 2018-12-20 13:46 bhaible Name => Bruno Haible 2018-12-20 13:46 bhaible Organization => GNU 2018-12-20 13:46 bhaible Section => --- 2018-12-20 13:46 bhaible Page Number => --- 2018-12-20 13:46 bhaible Line Number => --- 2020-10-05 11:11 geoffclare Note Added: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 15:45 bhaible Note Added: 0005027 2020-10-05 17:57 shware_systems Note Added: 0005030 2020-10-05 17:58 shware_systems Note Edited: 0005030 2020-10-07 13:29 geoffclare Note Added: 0005035 2020-10-07 15:08 shware_systems Note Added: 0005037 2020-10-23 14:21 geoffclare Note Added: 0005059 2020-10-23 15:57 shware_systems Note Added: 0005062 2020-10-26 10:03 geoffclare Note Added: 0005063 2020-10-26 14:50 shware_systems Note Added: 0005065 2020-10-26 16:16 geoffclare Note Added: 0005067 2020-10-29 18:25 shware_systems Note Added: 0005085 2020-10-30 09:23 geoffclare Note Added: 0005086 2020-10-30 18:23 shware_systems Note Added: 0005088 ======================================================================
