[PATCH] libstdc++: implement locale support for AIX

CHIGOT, CLEMENT clement.chigot@atos.net
Thu Jan 21 12:48:17 GMT 2021


Hi everyone, 

Here is a new version of the patch. I've tested on Linux and AIX.
There are still some tests failing but it starts having a good shape ! 
However, I have few questions:

1) locale.name and syscalls
locale.name() is returning a string having the description of each locale
category. It looks like 
"LC_CTYPE=en_US.UTF-8; LC_NUMERIC=en_US.UTF-8; ...".
However, in locale::global() or sometimes in c_locale.cc functions, this
name is used as arguments of setlocale, newlocale, etc. 
It seems to work with GNU locale model but when I'm trying to do it 
with the POSIX_2008 model, it doesn't work. A simple C program 
seems to refuse it, anyway.
Thus, is there any define on Linux enabling this behavior ? And in 
a more general way, I'm not sure it will work on all POSIX 2008 
system. We might need to modify std:global() and other functions 
ending up using locale.name() as syscalls argument. 

2) Detect locale model during tests
Is there already a function in the testsuite to detect which locale model
is being used ? I didn't find any and as I'm not use to runtest scripts, 
I don't really know how to implement one. 
Ideally, it would be something like "has_locale_modele { gnu }". It would 
allow to skip some tests which are made only for GNU model.
Is there any function I can based myself on ?  

3) POSIX 2017 and non-POSIX functions
Many of the *_l functions being used in GNU or dragonfly models aren't 
POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all. 
However, there are really useful in the code, thus I've made a double 
implementation based on "#ifdef HAVE_". Is it ok for you ? It's not really
POSIX 2008 but more POSIX 2008 with 2017 compatibility. 
For the configure, I didn't find any better way to check each syscall, as 
they all depend on different includes. Tell me if you have a better idea.

4) ctype_configure_char.cc 
I've some troubles knowing what is supposed to be implemented on this file. 
I don't really understand the part with setlocale which appears in many 
os. When I'm adding it, some tests start failing, some start working... 
Moreover, on Linux, if I understand correctly, there is some optimizations 
based on classic_table(), _M_toupper and _M_tolower. Could you confirm 
that it's only useful on Linux ?

5) Some tests results
Here are the remaining tests failing on Linux x86:
FAIL: 22_locale/locale/cons/29217.cc execution test
FAIL: 22_locale/locale/cons/38368.cc execution test
FAIL: 22_locale/locale/cons/40184.cc execution test
FAIL: 22_locale/locale/cons/5.cc execution test
FAIL: 22_locale/locale/global_locale_objects/14071.cc execution test
 => linked to 1)

FAIL: 22_locale/messages/13631.cc execution test
FAIL: 22_locale/messages/members/char/1.cc execution test
FAIL: 22_locale/messages/members/char/2.cc execution test
FAIL: 22_locale/messages/members/char/wrapped_env.cc execution test
FAIL: 22_locale/messages/members/char/wrapped_locale.cc execution test
FAIL: 22_locale/messages_byname/named_equivalence.cc execution test
  => linked to message_members.cc not being implemented.
        Reason behind 2)

FAIL: 22_locale/numpunct/members/char/3.cc execution test
  => No idea yet. Maybe 1) too.

FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
  => Not related. 

Feel free to try in on other OS. But I've made modifications only for AIX and 
Linux, as I can test the other ones. 

Thanks, 
Clément
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-libstdc-implement-locale-support-for-POSIX-2008.txt
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20210121/aefd5847/attachment-0001.txt>


More information about the Libstdc++ mailing list