From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 6B5463858C60 for ; Tue, 9 Nov 2021 07:09:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B5463858C60 Received: by mail-wm1-x32c.google.com with SMTP id g191-20020a1c9dc8000000b0032fbf912885so1491517wme.4 for ; Mon, 08 Nov 2021 23:09:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nAkcvl5IOQ5I5MeWSuCCsyJebzA7nHIkaM7yx5qrrVE=; b=e+lnrXBwZAy9e7fG+Khck0462hqtdawR8YpbmOvvdFCZeebp4fDorfsfSaOUY33Gk5 6/rcCktp/sBjd04WllLQOuCNPxFsysMRULEfTHNpMJXZmXAp1qrLT6NCniCTgCUZXa7b hOxVnrOonodMDp7n5q7EkGAYEGH6PRletO5LLSqRrH7rSKFZ9qaNFgpat01vSJLVBEYu Wi+NBK1LfZ0JdnZzt4d0I9MjpV5k70HkIg+KHR1grYU7YbzU7IpZwAyrbYESNEmETG9S tgrccb9a8l1173QJpK/k4xKJs0tyYas5JEYCj29qnzDmkx7i+QLq1Bd7sQ92u1jXJVcR 5lUQ== X-Gm-Message-State: AOAM531ChPAh2OLO5ltd6Sb8cDMvM1fcevCXB/uKOgUeEvtuU4BsGop6 rn6FsOwHw3Y+p9eTQLjZzEQ= X-Google-Smtp-Source: ABdhPJx2EbypLFxxbLL0Xc7KBSggdw6pbe0NC63+SAkMuelcWFZDROrPI2pJeMHfBqb/Xh9NpJVY2Q== X-Received: by 2002:a1c:9a89:: with SMTP id c131mr4660206wme.80.1636441755316; Mon, 08 Nov 2021 23:09:15 -0800 (PST) Received: from nbbrfq (91-119-98-250.dsl.dynamic.surfer.at. [91.119.98.250]) by smtp.gmail.com with ESMTPSA id n184sm1537496wme.2.2021.11.08.23.09.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Nov 2021 23:09:14 -0800 (PST) Date: Tue, 9 Nov 2021 08:09:10 +0100 From: Bernhard Reutner-Fischer To: Jason Merrill Cc: rep.dot.nop@gmail.com, Marek Polacek , Marek Polacek via Gcc-patches , Jakub Jelinek Subject: Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940] Message-ID: <20211109080910.2eae4f69@nbbrfq> In-Reply-To: References: <20210920190809.GM304296@tucnak> <8636350f-e588-12d1-b687-89245de0b62d@redhat.com> <89690210-3ac3-9486-1fa0-742fc67d3748@redhat.com> <84D9B2CE-EA9B-46FB-9BF5-809D29B7018E@gmail.com> <516f3ddd-8634-9d73-ddd4-ae470f4284cf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 07:09:18 -0000 On Tue, 9 Nov 2021 00:12:10 -0500 Jason Merrill wrote: > On 11/8/21 20:41, Marek Polacek wrote: > > On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: > > + for (auto opt : v) > > + { > > + char *cln = strstr (opt, "::"); > > + /* We don't accept '::attr'. */ > > + if (cln == nullptr || cln == opt) > > + { > > + error ("wrong argument to ignored attributes"); > > + inform (input_location, "valid format is % or %"); > > + continue; > > + } > > + char *vendor_start = opt; > > + ptrdiff_t vendor_len = cln - opt; > > + char *attr_start = cln + 2; > > + /* This could really use rawmemchr :(. */ > > + ptrdiff_t attr_len = strchr (attr_start, '\0') - attr_start; > > + /* Verify that they look valid. */ > > + auto valid_p = [](const char *const s, ptrdiff_t len) { > > + for (int i = 0; i < len; ++i) > > + if (!ISALNUM (*s) && *s != '_') > > + return false; > > + return true; > > + }; > > + if (!valid_p (vendor_start, vendor_len) > > + || !valid_p (attr_start, attr_len)) > > + { > > + error ("wrong argument to ignored attributes"); > > + continue; > > + } > > + /* Turn "__attr__" into "attr" so that we have a canonical form of > > + attribute names. Likewise for vendor. */ > > + auto strip = [](char *&s, ptrdiff_t &l) { > > + if (l > 4 && s[0] == '_' && s[1] == '_' > > + && s[l - 1] == '_' && s[l - 2] == '_') > > + { > > + s += 2; > > + l -= 4; > > + } > > + }; > > + strip (attr_start, attr_len); > > + strip (vendor_start, vendor_len); > > + /* We perform all this hijinks so that we don't have to copy OPT. */ > > + tree vendor_id = get_identifier_with_length (vendor_start, vendor_len); > > + tree attr_id = get_identifier_with_length (attr_start, attr_len); > > + /* If we've already seen this vendor::attr, ignore it. Attempting to > > + register it twice would lead to a crash. */ > > + if (lookup_scoped_attribute_spec (vendor_id, attr_id)) > > + continue; > > Hmm, this looks like it isn't handling the case of previously ignoring > vendor::; it seems we'll look for vendor:: instead, not > find it, and register again. I don't know if there are __attrib with 2 leading underscores but no trailing that we accept and should normalize? And it is surprising that we do not have a simple normalize_attr_name(). There must be existing spots where we would normalize attribute names? extract_attribute_substring does about the same but with a struct substring(?). Maybe that's just to avoid a normal string hash. thanks,