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 ESMTP id AA2663890037 for ; Fri, 11 Jun 2021 16:01:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA2663890037 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-390-CiCAbmdnPt6K5Rbc2BixCg-1; Fri, 11 Jun 2021 12:01:49 -0400 X-MC-Unique: CiCAbmdnPt6K5Rbc2BixCg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CB432100C618; Fri, 11 Jun 2021 16:01:48 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-114-102.ams2.redhat.com [10.36.114.102]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5BD8C10016FE; Fri, 11 Jun 2021 16:01:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 15BG1jY9579145 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Jun 2021 18:01:45 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 15BG1hK7579144; Fri, 11 Jun 2021 18:01:43 +0200 Date: Fri, 11 Jun 2021 18:01:43 +0200 From: Jakub Jelinek To: Tom Honermann Cc: Joseph Myers , gcc-patches Subject: Re: [PATCH 1/3]: C N2653 char8_t: Language support Message-ID: <20210611160143.GU7746@tucnak> Reply-To: Jakub Jelinek References: <38ba1356-652d-c2d0-f665-0024d9a946a4@honermann.net> MIME-Version: 1.0 In-Reply-To: <38ba1356-652d-c2d0-f665-0024d9a946a4@honermann.net> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 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_H4, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 16:01:53 -0000 On Fri, Jun 11, 2021 at 11:52:41AM -0400, Tom Honermann via Gcc-patches wrote: > On 6/7/21 5:11 PM, Joseph Myers wrote: > > On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote: > > > > > When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE macro > > > is predefined. This is the mechanism proposed to glibc to opt-in to > > > declarations of the char8_t typedef and c8rtomb and mbrtoc8 functions proposed > > > in N2653. See [2]. > > I don't think glibc should have such a feature test macro, and I don't > > think GCC should define such feature test macros either - _*_SOURCE macros > > are generally for the *user* to define to decide what namespace they want > > visible, not for the compiler to define. Without proliferating new > > language dialects, __STDC_VERSION__ ought to be sufficient to communicate > > from the compiler to the library (including to GCC's own headers such as > > stdatomic.h). > > > In general I agree, but I think an exception is warranted in this case for a > few reasons: > > 1. The feature includes both core language changes (the change of type > for u8 string literals) and library changes.  The library changes > are not actually dependent on the core language change, but they are > intended to be used together. > 2. Existing use of the char8_t identifier can be found in existing open > source projects and likely exists in some closed source projects as > well.  An opt-in approach avoids conflict and the need to > conditionalize code based on gcc version. > 3. An opt-in approach enables evaluation of the feature prior to any > WG14 approval. But calling it _CHAR8_T_SOURCE is weird and inconsistent with everything else. In C++, there is __cpp_char8_t 201811L predefined macro for char8_t. Using that in C is not right, sure. Often we use __SIZEOF_type__ macros not just for sizeof(), but also for presence check of the types, like #ifdef __SIZEOF_INT128__ __int128 i; #else long long i; #endif etc., while char8_t has sizeof (char8_t) == 1, perhaps predefining __SIZEOF_CHAR8_T__ 1 instead of _CHAR8_T_SOURCE would be better? Jakub