From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id F2399396AC04 for ; Fri, 11 Jun 2021 16:29:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2399396AC04 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: /6wAAYhSiBGleMos1zyKhuuULJeyf2gftcxkWP5x9X30b6plPLj6Tp6XBr/0TvUhDzKtFgNmE0 r1/3eymSvWakLut4vBQtOF9pUHCzhNbD815UUhbQSqTsQsJ51NfSMRb9U8BCWHbkei8VtyxUl+ BXlmdmRuouASjezWImVPBxHULBdG0zxopy+ziWqceEX7ttg4erpy0BFN5ieRmS9x1I/7Qf5k9S S257YR3CGUkApX2ukE2/nZ+O0fgvNkljXrcTThiGUEUSYyOr/iYDjfke+04Dy2t9cj51xFXhu/ xNU= X-IronPort-AV: E=Sophos;i="5.83,265,1616486400"; d="scan'208";a="64727456" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 11 Jun 2021 08:29:03 -0800 IronPort-SDR: Z0IBlY10dYdEWiL+1DYmIyq0sZ4sBxjVL/qkohkax7rLchB/hBgbZeEUPVYTJOL5hvg5q0hjsH mflSP0a48o9LWAeK0Yo0EdRb7zcK1rPt9MQBLr3e5xmSa95YrRaXbR2hdNo/W7U/5R1Sr1bB5A VwsVtsJJjKaBa8I6TnHA8xOG7Xh6zWon0o4Nr9F4HCPjX3zUT53rtAUcKRVLYy5TrFT6nb3y6W R1B5Y6KKThygPFvV1qdpBvz3UmdFs3oXFPdfYkY5CVmmVi5hrektc5ifYg2F44Dk0cO1buL3Ok 7VM= Date: Fri, 11 Jun 2021 16:28:58 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Tom Honermann CC: libc-alpha Subject: Re: [PATCH 2/3]: C++20 P0482R6 and C2X N2653: Implement mbrtoc8, c8rtomb, char8_t In-Reply-To: <1c33efce-b4ed-a238-aa3a-7b15fa3dd495@honermann.net> Message-ID: References: <40868945-29d9-3099-fb11-260796a2a022@honermann.net> <1c33efce-b4ed-a238-aa3a-7b15fa3dd495@honermann.net> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3120.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 16:29:06 -0000 On Fri, 11 Jun 2021, Tom Honermann via Libc-alpha wrote: > 1) Enabling pre-C2x compatibility with C++20. Where a feature in a header should be enabled for a particular C++ version, we can have an internal __GLIBC_USE (CXX20) which is enabled based on the value of __cplusplus, just like the existing __USE_ISOCXX11. (Though that doesn't make much practical difference until we provide a way for C++ library headers to get all the features they need without defining _GNU_SOURCE.) You'd then have #if defined __USE_GNU || __GLIBC_USE (CXX20) in uchar.h, with appropriate !defined __cpp_char8_t for defining the typedef itself. And the defined __USE_GNU would become __GLIBC_USE (ISOC2X) if the feature is accepted for C2x. > 2) Enabling conditional code sensitive to the change of type of u8 string > literals. That might be a reason for a compiler option (I don't think it's a sufficient reason, I expect -std=c11 or -Wno-pointer-sign or pointer casts to suffice in practice), but it has nothing to do with the use of feature test macros in glibc since the library headers don't care at all what the type of u8 string literals is (there are no u8 string literals anywhere in glibc). > 3) Avoiding clashes with existing uses of the char8_t identifier in code that > may be compiled with _GNU_SOURCE. It's a universal feature in glibc that all non-obsolescent, non-conflicting features are enabled with _GNU_SOURCE, including features from future standard versions - all feature test macros are subsets of _GNU_SOURCE, except where the features actually conflict in some way (a few cases where a POSIX function has semantics incompatible with a GNU function of the same name), and features from future standards with no feature test macro support in glibc (e.g. some features proposed for the next POSIX version) are also enabled by _GNU_SOURCE. So char8_t and these functions should be enabled by _GNU_SOURCE, regardless of what other options enable them. Users of _GNU_SOURCE are expected to deal with possible naming conflicts with features added to _GNU_SOURCE. Likewise people building with -std=gnu2x / -std=c2x, which would enable these declarations if char8_t and these functions are added to C2x, or users of _ISOC2X_SOURCE (which isn't expected to be used much). > I agree that this is a narrow feature, but I think the feature test macro is > beneficial for compatibility reasons.  Assuming the proposal is adopted for > C23, some programmers may need to opt-out of the feature by compiling with > -fno-char8_t during a migration period; as some C++20 projects have done. We don't provide a way to opt out of any other library additions when compiling in C2x mode; compiling with -std=c2x or -std=gnu2x or -D_GNU_SOURCE unconditionally enables all other C2x additions in headers (including e.g. the iszero macro, although the issues seen with that were mainly for C++ code and we addressed that by making it a template instead of a macro for C++), compiling with e.g. -std=c11 or -std=gnu11 (and not using _GNU_SOURCE) is how you opt out of all such additions at the same time. Likewise for previous C standard versions. And _GNU_SOURCE is the universal way to opt in to features that might or might not be in a future standard version. If such a feature has its own TS, we may support the __STDC_WANT_* macros from such a TS, but that's not a basis for creating our own feature test macro for a handful of new identifiers. -- Joseph S. Myers joseph@codesourcery.com