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.129.124]) by sourceware.org (Postfix) with ESMTPS id 007893856975 for ; Thu, 16 Feb 2023 12:00:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 007893856975 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=1676548820; 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: in-reply-to:in-reply-to:references:references; bh=qKmqlyJ6OWUBw4oQQCaPq/Ow7KzfykKJNBoi+bOwsbs=; b=gxgAOID0/flwpNQpU/nvLYDtU6gekF/vN+5rEY67GwVmg6xSfbsywOob+U4mD/68yhO64u RRvumBFus0F5Xvu+FuJp5Ny5GLcV+GolXdIxaP2SFGZQA64V6M0wSPazd1nPkUQnd4Db/n UmJPH9S2oI1Q0asxwoAohof5nPehoRU= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-609-k9k8O1UNPBStHsLAdNz1vA-1; Thu, 16 Feb 2023 07:00:19 -0500 X-MC-Unique: k9k8O1UNPBStHsLAdNz1vA-1 Received: by mail-lf1-f71.google.com with SMTP id u4-20020a056512040400b004dc6259b7acso192776lfk.6 for ; Thu, 16 Feb 2023 04:00:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qKmqlyJ6OWUBw4oQQCaPq/Ow7KzfykKJNBoi+bOwsbs=; b=a44WNNoKdiHk3wvig0A7cI7RzCePvaubcGcpuuM0TucJd39wfukknEALSB8disG01l qRitQtZdy9tVPE1G3fuZvPHaGSncZVBBiA3mFzE5Wz/w59QPp00LbAS5BOL2TCujhlg3 wQvlHgHJMYAEYsMEdPorEfXKAofItwryi4bIr4nqsjkro75LieFw5D1SBFzuBDJjf58u UmIIrhi12Gqt8b57a6wlYhFzhnPHj/IKwKjmoX0bFzu3pevmlZ/Tpd6QWkKjV5Vdmxjd 2M6FjEaXMg3CYYkRwT/djyCY+4sMDZ7XbZf2xZvzgPeqmp72APJLNgfuxfmzM6scjyc5 fZMA== X-Gm-Message-State: AO0yUKW8D+cTPabgn0NmLct3wWhqidH/yjE0ZnwOfgvejx2RphaJMrFr z/BOTM1Z2IskNT1EBasVR0PMNLyCjFYkzSTKvT326HKAoIJyvHw7zXU0MRNgxc50hxNl7zpFdA+ xceMdw/8nW/ISoYjsOqAZfDV56M/D1FQ= X-Received: by 2002:ac2:5296:0:b0:4db:173e:812a with SMTP id q22-20020ac25296000000b004db173e812amr1577553lfm.8.1676548817858; Thu, 16 Feb 2023 04:00:17 -0800 (PST) X-Google-Smtp-Source: AK7set+BRHe15Rc0kZDqlkSeWhKB6fLQ+cHB82awH/UFvdGrbMp4PQdnlDI9+G251DUruGOL/JiSiXeZTKzMKKdMpdQ= X-Received: by 2002:ac2:5296:0:b0:4db:173e:812a with SMTP id q22-20020ac25296000000b004db173e812amr1577547lfm.8.1676548817558; Thu, 16 Feb 2023 04:00:17 -0800 (PST) MIME-Version: 1.0 References: <20230216103030.94868-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 16 Feb 2023 12:00:06 +0000 Message-ID: Subject: Re: [committed] libstdc++: Fix uses of non-reserved names in headers To: Jakub Jelinek Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.2 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, 16 Feb 2023 at 10:48, Jakub Jelinek wrote: > > 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. We could, but it seems like a lot of work just for "val" and "dest", when there are much simpler solutions :-)