From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 4BBD839960F6 for ; Tue, 30 Aug 2022 21:10:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BBD839960F6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,276,1654588800"; d="scan'208";a="82184824" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 30 Aug 2022 13:10:42 -0800 IronPort-SDR: XPMa+GkH8RVyYwwunIWhOB/4f3rzsbFvEuGDbMePseSvrsmD9VoRlLkjlVrOJ4tjTPfZxWTrCA z3mH08fMwiobE0gKxGzoSd/OJDZ78/OQy0qDObxgq59O+79qlLBmeA1BhpFTSqFnt5hFrHgp5S T97R7Ln79ARBJl50pO95dj6E9r3NQfV1u/19eamgRhStsr4tXIKvtPbI2xtvif+vnaYJA3i793 Pyk8iDkO2e/XVP1L+wVlI1ijkh1Cuu5unoNvFXrQGblCHPNSFMs9Hgu6xjhlhgpbQP7p80qe8W DTA= Date: Tue, 30 Aug 2022 21:10:37 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jakub Jelinek CC: Jason Merrill , Subject: Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648] In-Reply-To: Message-ID: References: <4fcd7e74-6f1c-dbec-a42c-e4e3fd13470b@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3111.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. -- Joseph S. Myers joseph@codesourcery.com