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 E569A3858D33 for ; Thu, 16 Feb 2023 10:48:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E569A3858D33 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=1676544519; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=MpJvTBfwHYYxFGPp1xDRSYT96mcG4hOyDF232Gc6B2k=; b=bnAKzbGQgqAfq3qw5amN8nE9lH0DnY85mal0w+7U2daULgWHWYdYat5JpVWx9WmbtrH9Nv S/7mWwpPlGPEwzid8L63EuhQQBwt9XaGhZj2j984lJjbGXpMbB/Fy34caFzZdxdLUKTFkk xr71W26yko8y1+hBsqK8EVx9HL6bvh8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-128-zPl3u_WdO46p3JiToLbhxg-1; Thu, 16 Feb 2023 05:48:38 -0500 X-MC-Unique: zPl3u_WdO46p3JiToLbhxg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 16D5C385F364; Thu, 16 Feb 2023 10:48:38 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.203]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C1572175AD; Thu, 16 Feb 2023 10:48:37 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 31GAm9lt2902529 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 16 Feb 2023 11:48:09 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31GAm3LJ2902526; Thu, 16 Feb 2023 11:48:03 +0100 Date: Thu, 16 Feb 2023 11:47:54 +0100 From: Jakub Jelinek To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [committed] libstdc++: Fix uses of non-reserved names in headers Message-ID: Reply-To: Jakub Jelinek References: <20230216103030.94868-1-jwakely@redhat.com> MIME-Version: 1.0 In-Reply-To: <20230216103030.94868-1-jwakely@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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 Thu, Feb 16, 2023 at 10:30:30AM +0000, Jonathan Wakely via Gcc-patches wrote: > Tested powerpc64le-linux. Pushed to trunk. > > These should be backported too. > > -- >8 -- > > The non-reserved names 'val' and 'dest' were being used in our headers > but haven't been added to the 17_intro/names.cc test. That's because > they are used by and > respecitvely on glibc-based systems. So, can't we for such problematic names add hacks, like some directory which the test adds as -isystem before the standard ones and contains some header wrappers which temporarily #undef val #undef dest (or whatever other name), then #include_next ... and then define them again? Doesn't need to be for all targets of course, but just something to cover at least the most common ones. Or perhaps even do it differently, add 2 headers, one which defines all those #define whatever (, one that #undef whatever them all, and add wrappers in a -isystem directory for all non-gcc owned headers used by the libstdc++ headers, which would include this #undef header first and #define at the end. That way we wouldn't test non-reserved names in say libc headers, just in libstdc++ headers. What both of these break though is if libstdc++ headers try to use __has_include etc. on them, because the added wrapper will mean they will show as existing. Jakub