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

[Jonathan Wakely <jwakely@redhat.com>]

On 21/01/21 17:36 +0100, Rainer Orth wrote:
>Hi Clement,
>
>> 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
>
>just a terminology nit: none of those are syscalls.
>
>> 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.
>
>First a general observation: there are two groups of functions you're
>testing for:
>
>* Pure BSD additions, not available in either POSIX.1, ISO C, or glibc:
>
>  localeconv_l
>  mbstowcs_l
>  strtod_l
>  strtof_l
>  strtold_l
>  wcsftime_l

Glibc does provide the last four with _GNU_SOURCE defined (but not
localeconv_l or mbstowcs_l).

>
>* Part of XPG7:
>
>  iswctype_l
>  strcoll_l
>  strftime_l
>  strxfrm_l
>  towlower_l
>  towupper_l
>  wcscoll_l
>  wcsxfrm_l
>  wctype_l
>
>My suggestion would be not to have configure tests _GLIBCXX_HAVE_<FUNC>
>for any of the second group at all: this is ieee_1003.1-2008, after all,
>so if some OS selects that clocale variant, it better implement all of
>those.  If really need be, one could a configure check for those and
>error out if any is missing.  This makes the code way more readable than
>trying to handle some hypothetical partial implementation.

Agreed.

>As for the BSD group, I suggest to have one representative configure
>test (for localeconv_l perhaps) and then use an appropriate name for the
>group as a whole.  Again, this will most likely be an all-or-nothing
>thing.
>
>Besides, your configure tests are way too complicated: just use
>AC_CHECK_FUNCS doing a link test and be done with it.
>
>In a similar vein, configure.ac already has
>AC_CHECK_HEADERS([xlocale.h]).  Rather than hardcoding the existance of
>the header based on the configure triple, just use the existing
>HAVE_XLOCALE_H.  This ways, things will simply fall into place for
>e.g. NetBSD, OpenBSD and possibly others.

IIRC Darwin has that header, but I'm not sure how many of the xxx_l
extensions it provides.