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

["CHIGOT, CLEMENT" <clement.chigot@atos.net>]

Hi Rainer, Jonathan

>>>why?  I've just double-checked the OpenGroup pages: all of the functions
>>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>>have Technical Corrigenda applied.  IIUC IEEE 1003.1-2017 is just a
>>>revision of the -2008 standard, not a new issue (XPG8 or something).
>>
>> Technically, the 2008 standard has been withdrawn and replaced by
>> 2017. Since the content is the same, it seems more correct to refer to
>> the current standard (even if Solaris only documents support for the
>> 2008 edition, if it also implements the corrigenda then it conforms to
>> 2017 even if it doesn't document that).
>
>I've found no macro that would distinguish P1003.1-2008 and -2017.  It
>seems both are identified by _XOPEN_SOURCE=700 and
>_POSIX_C_SOURCE=200809L.
>
>> But as I said, a shorter, more memorable name like "xpg7" or just
>> "posix" might be preferable anyway.
>
> I'd strongly prefer xpg7 over posix: after all, xpg6 systems are still
> around (Solaris 11.3 being one of them, and I suspect older AIX versions
> as well).  It's certainly much less of a mouthful than ieee_1003.1-2008 ;-)

I honestly don't master all these conventions. So I'll follow you on the right
name to give.

>> Some are still needed as for example only the last version of AIX have
>> strftime_l.
>
> Then that version doesn't conform to XPG7 and shouldn't use that clocale
> variant.  Until we have a clearer understanding of the variation here,
> I'd argue that only P1003.1-2008 conforming OSes should use
> ieee_1003.1-2008, rather than creating an impenetrable maze of #ifdefs
> for all sorts of partial implementations.

Yes, AIX before 7.2 TL5 is Unix03 compliant, and after UNIXv7.
However, my aim is to implement locale support for these older versions
too. Thus, maybe I can create a fake strftime_l in config/os/aix. But I want
to use this model for AIX. Otherwise, I'll simply revert to the AIX model
as I've made in the first patch, as it's not possible to use this new
model for my purpose.
I mean no offense, but my aim is to improve AIX. Of course,
I'm glad to help other OS too, but I can't work on it if there is no
impact for AIX at the end.

>>>> Besides, your configure tests are way too complicated: just use
>>>> AC_CHECK_FUNCS doing a link test and be done with it.
>>>
>>> Sadly, you can't pass includes to AC_CHECK_FUNCS. That's why I had to do
>>> that. I've made a first version with AC_CHECK_DECLS which allows extra
>>> headers, but it didn't work too. I might know why though.
>>
>>Why would you need to?  AC_CHECK_FUNCS just perform a link test to check
>>if the functions are present in libc; no need to have a declaration
>>present.
>
>Right, I wondered about this too.

I didn't work when I've tried. Maybe I've missed something. I'll check.

Thanks,
Clément
________________________________
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Sent: Friday, January 22, 2021 12:54 PM
To: Jonathan Wakely <jwakely@redhat.com>
Cc: CHIGOT, CLEMENT <clement.chigot@atos.net>; libstdc++ <libstdc++@gcc.gnu.org>; David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org>; David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH] libstdc++: implement locale support for AIX

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Jonathan,

> On 22/01/21 12:04 +0100, Rainer Orth wrote:
>>why?  I've just double-checked the OpenGroup pages: all of the functions
>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>have Technical Corrigenda applied.  IIUC IEEE 1003.1-2017 is just a
>>revision of the -2008 standard, not a new issue (XPG8 or something).
>
> Technically, the 2008 standard has been withdrawn and replaced by
> 2017. Since the content is the same, it seems more correct to refer to
> the current standard (even if Solaris only documents support for the
> 2008 edition, if it also implements the corrigenda then it conforms to
> 2017 even if it doesn't document that).

I've found no macro that would distinguish P1003.1-2008 and -2017.  It
seems both are identified by _XOPEN_SOURCE=700 and
_POSIX_C_SOURCE=200809L.

> But as I said, a shorter, more memorable name like "xpg7" or just
> "posix" might be preferable anyway.

I'd strongly prefer xpg7 over posix: after all, xpg6 systems are still
around (Solaris 11.3 being one of them, and I suspect older AIX versions
as well).  It's certainly much less of a mouthful than ieee_1003.1-2008 ;-)

>>>> 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.
>>>
>>> I'm not sure this is really all-or-nothing for these. Maybe strtof_l and cie
>>> can be grouped by. But the 3 others are really different. Linux have
>>> wcsftime_l
>>> but not the others. AIX avec none. BSD have all.
>>
>>TBH, I don't care about Linux here: it will continue to use the gnu
>>variant anyway.  Besides, since the patch will have to work on targets
>>without wcsftime_l and the other BSD functions, I don't see any harm in
>>not using one non-standard one of them although it's present.
>
> I agree that GNU/Linux will continue to use the gnu model, but it can
> still be usable as a useful extra test of the code's portablility,
> since it implements everything in XPG7 (and more). We shouldn't spend
> any effort doing linux-specific changes in this new model, since they
> won't be used in practice. But if it works "out of the box" with no
> tweaks, then that is useful for testing.

Absolutely: the more different implementation we can throw at the code,
the better for portability.

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University