From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by sourceware.org (Postfix) with ESMTPS id 8D0BB388A811 for ; Wed, 13 May 2020 08:07:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D0BB388A811 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dodji@seketeli.org X-Originating-IP: 91.166.131.130 Received: from localhost (91-166-131-130.subs.proxad.net [91.166.131.130]) (Authenticated sender: dodj@seketeli.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id E71011BF212; Wed, 13 May 2020 08:07:08 +0000 (UTC) Received: by localhost (Postfix, from userid 1001) id 9D5681A4BFF; Wed, 13 May 2020 10:07:07 +0200 (CEST) From: Dodji Seketeli To: Giuliano Procida Cc: libabigail@sourceware.org, kernel-team@android.com, maennich@google.com Subject: Re: [PATCH v4 10/15] Compile suppression regexes earlier. Organization: Me, myself and I References: <20200424092132.150547-1-gprocida@google.com> <20200504123416.243214-1-gprocida@google.com> <20200504123416.243214-11-gprocida@google.com> X-Operating-System: Red Hat Enterprise Linux Server 7.7 X-URL: http://www.seketeli.net/~dodji Date: Wed, 13 May 2020 10:07:07 +0200 In-Reply-To: <20200504123416.243214-11-gprocida@google.com> (Giuliano Procida's message of "Mon, 4 May 2020 13:34:11 +0100") Message-ID: <864kskfec4.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 08:07:12 -0000 Giuliano Procida a =C3=A9crit: > Regexes are used in suppression specifications for various things. > They are currently compiled on first use, rather than on construction > of the specifications. > > This patches changes the suppression specification types to hold > compiled regexes directly which is a significant simplification and is > a prerequisite for early error reporting. [...] > diff --git a/include/abg-suppression.h b/include/abg-suppression.h > index 6383b932..8256f9b8 100644 > --- a/include/abg-suppression.h > +++ b/include/abg-suppression.h > @@ -26,6 +26,7 @@ > #include "abg-cxx-compat.h" > #include "abg-ini.h" > #include "abg-comparison.h" > +#include "abg-regex.h" >=20=20 > namespace abigail > { > @@ -64,8 +65,8 @@ public: > suppression_base(const string& label); >=20=20 > suppression_base(const string& label, > - const string& file_name_regex_str, > - const string& file_name_not_regex_str); > + const regex::regex_t_sptr& file_name_regex, > + const regex::regex_t_sptr& file_name_not_regex); I am not against compiling the regular expressions early. However, I don't like leaking the regex_t type through the suppression API. I'd really prefer the compiled regular expression type to stay internal to the suppression API. In other words, existing users of the library who created suppressions just using regular expressions strings (as opposed to compiled regular expressions) to interact with the API should be able to continue to do so. This breaks the API compatibility un-necessarily, IMHO. I'd like to avoid that. And I don't think it's a design flaw to interact with the API just through strings, as opposed to using it through regex_t, quite the opposite. It was a design decision that I tried to stick to throughout the library. The reader interface does't leak the underlying XML library types. The dwarf reader doesn't leak the types of the underlying facilities we use, etc. So I'd like this to stay consistent accross the library. I am sorry to tell you this this late. I could have saved you a lot of work; I didn't realize in our discussions that this was what you wanted to do. Cheers, --=20 Dodji