[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