From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 6C6C0398C80A for ; Fri, 22 Jan 2021 11:02:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6C6C0398C80A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-449-OihP0-1jOwSvNOHIngtFlQ-1; Fri, 22 Jan 2021 06:02:41 -0500 X-MC-Unique: OihP0-1jOwSvNOHIngtFlQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DD44C84A5E1; Fri, 22 Jan 2021 11:02:38 +0000 (UTC) Received: from localhost (unknown [10.33.36.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2FAC762679; Fri, 22 Jan 2021 11:02:37 +0000 (UTC) Date: Fri, 22 Jan 2021 11:02:37 +0000 From: Jonathan Wakely To: Rainer Orth Cc: "CHIGOT, CLEMENT" , libstdc++ , David Edelsohn via Gcc-patches , David Edelsohn Subject: Re: [PATCH] libstdc++: implement locale support for AIX Message-ID: <20210122110237.GG541588@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 11:02:59 -0000 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_ >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.