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 BBAE93858C50 for ; Thu, 16 Feb 2023 10:48:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBAE93858C50 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=1676544521; 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=RtYSq+O1vCC5ljDyLOVYrd8rfNPmFgMikYS51sNo+P+b9T/7ABE/1yKX0wbYtXFohbJinO O3rvUnDjgfifdehISjWYT7raxKcWNK1fJxQvy9VVdYcZ74QN5N6G4ziviKpi7Bs1ANsk9m ZklY64mrS4p6BBqzgfkqJmIMqdnakXY= 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=unavailable 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