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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 40C2F3858433 for ; Mon, 10 Jan 2022 13:23:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40C2F3858433 Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-444-3btAJxreNB-l_V0ZkAyK4A-1; Mon, 10 Jan 2022 08:23:34 -0500 X-MC-Unique: 3btAJxreNB-l_V0ZkAyK4A-1 Received: by mail-yb1-f198.google.com with SMTP id d127-20020a256885000000b006112fd779ddso3602880ybc.14 for ; Mon, 10 Jan 2022 05:23:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nOBiLK/6IiYMwbSPjPDNfUiTMS328FLb4lHeIMXgSjk=; b=3a+rYahUQcJ2fqyIrrHXJYIiaTwGw5wCt5FFjjkMnirRaF0PTE0NXsPdPlWHWVKBlD oOd0uLi/0OAG0wThZ9M58+3bcU8jmCdrr+tl2IrIeR00oHhdn9od0WxC3l+KTjpA9pn2 iceAUkAE+ic3BlC6W1qg5OsqWMtfUwUvBrrF0hCMyIIHJFjdjD3Eu0xtsi0fpcGjeuno oBpQXgrxCrvolYsK/IXnZXhMIarMF9C+SZxBuQcNrR5p2/uLf975l+SHJqeZqod/dYIs oDrUCbhdY0O39dFp50GI7ADz1+NBuQy91i31UiOseFEBMvB5ovuv2c6QpYpbNCyugeRF Xj1Q== X-Gm-Message-State: AOAM531Rp6H0N9036T5chv24P2RI5FzYcyeNQoyJqeFHRmOyxS20EbSj OSgdjsZUAvgFUhTdeZ+jMO/y1dCZKBc83iwnBHihVpcJSNEaGqv0ucZWLacJ2Roax9l/G4WZjCd qbShV1dbAyGvt3gH8Z21k13NnmLcRa24= X-Received: by 2002:a25:9285:: with SMTP id y5mr13653985ybl.107.1641821013728; Mon, 10 Jan 2022 05:23:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZlj4UqTJQH38kjIn4eT6sJzeCtTuQ9QRPa88ZD1D3JtrB9w/hnt+0jWZwOul/W+TmDBH7TTjy1n1qtBa8O80= X-Received: by 2002:a25:9285:: with SMTP id y5mr13653964ybl.107.1641821013552; Mon, 10 Jan 2022 05:23:33 -0800 (PST) MIME-Version: 1.0 References: <79037d6b-3c48-eb7b-030a-f388fb988187@honermann.net> In-Reply-To: <79037d6b-3c48-eb7b-030a-f388fb988187@honermann.net> From: Jonathan Wakely Date: Mon, 10 Jan 2022 13:23:22 +0000 Message-ID: Subject: Re: [PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library To: Tom Honermann Cc: "libstdc++@gcc.gnu.org" , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 10 Jan 2022 13:23:39 -0000 On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++ < libstdc++@gcc.gnu.org> wrote: > This patch completes implementation of the C++20 proposal P0482R6 [1] by > adding declarations of std::c8rtomb() and std::mbrtoc8() in if > provided by the C library in . > > This patch addresses feedback provided in response to a previous patch > submission [2]. > > Autoconf changes determine if the C library declares c8rtomb and mbrtoc8 > at global scope when uchar.h is included and compiled with either > -fchar8_t or -std=c++20. New _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T > and _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 configuration macros > reflect the probe results. The header declares these functions > in the std namespace only if available and the _GLIBCXX_USE_CHAR8_T > configuration macro is defined (by default it is defined if the C++20 > __cpp_char8_t feature test macro is defined) > > Patches to glibc to implement c8rtomb and mbrtoc8 have been submitted [3]. > > New tests validate the presence of these declarations. The tests pass > trivially if the C library does not provide these functions. Otherwise > they ensure that the functions are declared when is included > and either -fchar8_t or -std=c++20 is enabled. > > Tested on Linux x86_64. > > libstdc++-v3/ChangeLog: > > 2022-01-07 Tom Honermann > > * acinclude.m4 Define config macros if uchar.h provides > c8rtomb() and mbrtoc8(). > * config.h.in: Re-generate. > * configure: Re-generate. > * include/c_compatibility/uchar.h: Declare ::c8rtomb and > ::mbrtoc8. > * include/c_global/cuchar: Declare std::c8rtomb and > std::mbrtoc8. > * include/c_std/cuchar: Declare std::c8rtomb and std::mbrtoc8. > * testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc: > New test. > * testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc: > New test. > Thanks, Tom, this looks good and I'll get it committed for GCC 12. My only concern is that the new tests depend on an internal macro: +#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 + using std::mbrtoc8; + using std::c8rtomb; I prefer if tests are written as "user code" when possible, and not using our internal macros. That isn't always possible, and in this case would require adding new effective-target keyword to testsuite/lib/libstdc++.exp just for use in these two tests. I don't think we should bother with that. I suppose strictly speaking we should not define __cpp_lib_char8_t unless these two functions are present in libc. But I'm not sure we want to change that now either.