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 F33563858D39 for ; Wed, 31 Aug 2022 14:18:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F33563858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661955528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ePIaPibo+J/g/l3B1uGJPpqDT6WKF5OuXQeinp6+zxw=; b=SIIjIg6osWVRSOp3Tx0hwBXEfP3ZTn2FNWp/JBblrpy1E54z7HcioqYeFpQG3F9XE4c6qK Buih+XGOZTuhuJnhh695xAc9s2uHZF7gpnvkLJZR9zQ8VVDsEWjVoKx4zlg7C7FjsBCAL7 JYT26s8fVI0sh+qFFNNfoNCR0Z10dtQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-468-XAUaI0bpMJmNkc8b76vcDA-1; Wed, 31 Aug 2022 10:18:45 -0400 X-MC-Unique: XAUaI0bpMJmNkc8b76vcDA-1 Received: by mail-qk1-f197.google.com with SMTP id bm11-20020a05620a198b00b006bb2388ef0cso11747355qkb.5 for ; Wed, 31 Aug 2022 07:18:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=ePIaPibo+J/g/l3B1uGJPpqDT6WKF5OuXQeinp6+zxw=; b=mVRHyUNwWPswijWPaW8AZ9t77OIOiswYdnLodcA0XUibFVrsN3CvSs6pKGJxEsTQql 6J4svC//a8ysw8nIz5LsJ0L1h3h74RL9PiNgiIjt5qmGDD79ygdoAsA06rWLq+Bbih8p n4KZKC/JeNu8U8FHFPFAvFJWqwhfs97kIIqbXuSKrLg1GzRnIbXex+ukV7FbCdncakWG kU1ohIxSxj68cGSzC6udLL09HgTMAZwPIDzfLvi+F407gGy8pHwDDWzG9KwSBFVibjOe FjZW+AXMe7zhdf6j1MBNcTxK20X4711thPF7bfLLSHEfOE5VtvvSAneqI9om3wMuP9co qhJw== X-Gm-Message-State: ACgBeo1AiDBg878hKCOm8AWs2vjKudjotss9l6GEvrktOdkP7JkswDEM ILiYsXqsHK9wpkQBR6WE+tNSJ2+Nyy7/p4rYiLTwtpPNufds48c5SPvgFRPXchiY1TaNUmAESq5 pax5xandGF2TBZj/eJw== X-Received: by 2002:a05:622a:199c:b0:344:7645:9ba1 with SMTP id u28-20020a05622a199c00b0034476459ba1mr19328066qtc.629.1661955524916; Wed, 31 Aug 2022 07:18:44 -0700 (PDT) X-Google-Smtp-Source: AA6agR4qh6Pno3iBRhbdKKTPsGRf7c+U6OCjNoLPBPti1620HcG8LFzE+PCpUeGyYpzRFepRFMwBZg== X-Received: by 2002:a05:622a:199c:b0:344:7645:9ba1 with SMTP id u28-20020a05622a199c00b0034476459ba1mr19328042qtc.629.1661955524542; Wed, 31 Aug 2022 07:18:44 -0700 (PDT) Received: from [192.168.1.101] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id bp8-20020a05620a458800b006b93ff541dasm10163681qkb.8.2022.08.31.07.18.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Aug 2022 07:18:43 -0700 (PDT) Message-ID: Date: Wed, 31 Aug 2022 10:18:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648] To: Jakub Jelinek , Joseph Myers Cc: gcc-patches@gcc.gnu.org References: <4fcd7e74-6f1c-dbec-a42c-e4e3fd13470b@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/30/22 17:37, Jakub Jelinek wrote: > On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote: >> On Tue, Aug 30, 2022 at 09:10:37PM +0000, Joseph Myers wrote: >>> I'm seeing build failures of glibc for powerpc64, as illustrated by the >>> following C code: >>> >>> #if 0 >>> \NARG >>> #endif >>> >>> (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef >>> __ASSEMBLER__). >>> >>> This shows some problems with this feature - and with delimited escape >>> sequences - as it affects C. It's fine to accept it as an extension >>> inside string and character literals, because \N or \u{...} would be >>> invalid in the absence of the feature (i.e. the syntax for such literals >>> fails to match, meaning that the rule about undefined behavior for a >>> single ' or " as a pp-token applies). But outside string and character >>> literals, the usual lexing rules apply, the \ is a pp-token on its own and >>> the code is valid at the preprocessing level, and with expansion of macros >>> appearing before or after the \ (e.g. u defined as a macro in the \u{...} >>> case) it may be valid code at the language level as well. I don't know >>> what older C++ versions say about this, but for C this means e.g. >>> >>> #define z(x) 0 >>> #define a z( >>> int x = a\NARG); >>> >>> needs to be accepted as expanding to "int x = 0;", not interpreted as >>> using the \N feature in an identifier and produce an error. >> >> Thanks, will look at it tomorrow. > > If > #define z(x) 0 > #define a z( > int x = a\NARG); > is valid in C and C++ <= 20 then > #define z(x) 0 > #define a z( > int x = a\N{LATIN SMALL LETTER A WITH ACUTE}); > is too and shall preprocess to int x = 0; too. > Which would likely mean that we want to only handle it in identifiers if > in C++23 and not actually treat it as an extension except in literals. > > Jason, your thoughts about that? The problem in glibc is with \N that is not followed by {; it certainly seems that we need to not treat that as an ill-formed named universal char escape outside of a literal. I think for an actual \N{...} sequence, we should treat it as an extension unless in strict conformance mode, kind of like we do with the ext_numeric_numerals flag. Jason