From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by sourceware.org (Postfix) with ESMTPS id 903BB384B00F for ; Tue, 6 Oct 2020 20:20:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 903BB384B00F Received: by mail-io1-xd43.google.com with SMTP id d20so9529665iop.10 for ; Tue, 06 Oct 2020 13:20:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1qMyvSflWS7tZeVvMWVl/q2LLT0JVChmpVm7erLNPeQ=; b=DcdJ/X2rsCMltM5Jq+OHBQXo7WXzTsVtj+yqR6mr/91CiN/eDSE8so6wSbXPkWOSqR y7fyU3zMbXW+4T7suzrWpTGkP2oFH6j6Bn5MbYJcDPnbOHQyW8DYp0JqZipf/LVDPFGt Ar1Ko4X7vwqW2/Kr1INKJ/84IKS5qA2Sl2VeFpNewQ9RDNO1ZIzKtB655DnFB5nP42ja Dp+NmhIZw7kE37VXyXtNbpLNG+eCjZjL8cq73P3gVAWlP2eoNLZYFJfqXZbFa5SxKmB5 4Zz8sXbZCHyH/k4XLY62kSfomX1bStMTlmiXGXxkE1+zLR3F1dSbUL/Wkld597zqYYO6 M7Ag== X-Gm-Message-State: AOAM531w9bPHD10AVsMb+CXr1KrAOgu8AF4LVthyxS1EXzT/7WZdxhoH GXgr3ApHLCU66OEBNqtoenHDIpifgXm4sbPGNB+HH+gBSnOqOLmR X-Google-Smtp-Source: ABdhPJy5yCm9gHcoNO9C2NnJH/cLGMz+t9vtFcOt27TkE9pDSyVhsAu8I0MJydtJYoLdxx1TaW1E23OBdZF8bYrqTB8= X-Received: by 2002:a02:a10f:: with SMTP id f15mr2935539jag.62.1602015610765; Tue, 06 Oct 2020 13:20:10 -0700 (PDT) MIME-Version: 1.0 References: <20200817093819.172380-1-gprocida@google.com> <87k0w9ozrz.fsf@seketeli.org> In-Reply-To: <87k0w9ozrz.fsf@seketeli.org> From: Giuliano Procida Date: Tue, 6 Oct 2020 21:19:34 +0100 Message-ID: Subject: Re: [PATCH 0/7] Suppression parsing - preparatory work To: Dodji Seketeli Cc: libabigail@sourceware.org, kernel-team@android.com X-Spam-Status: No, score=-23.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 06 Oct 2020 20:20:15 -0000 Hi there. On Fri, 2 Oct 2020 at 22:53, Dodji Seketeli wrote: > Hello Giuliano, > > Giuliano Procida a =C3=A9crit: > > > Quite a while ago I had a series of patches with the aim of improving > > libabigail's suppression parsing with the main aims: > > > > * adding error handling and reporting > > * refactoring for easier maintenance (both fixes and features) > > > > Early on in the series, I changed the way regexes were parsed and > > passed in and out of the suppression specifications. This wasn't > > something you were happy with, so I shelved the series. > > > > I've taken a lttle time to remove those changes and rebase the series. > > My plan is to feed changes to you in digistible batches. > > > > This batch contains: > > > > * 2 commits that fix issues in an uncontroversial way > > Thanks! I happily applied these. > > > * 3 commits to add the outer shell of error handling > > * 2 commits to simplify how suppressions are constructed > > > > The error handling commits do not add any error reporting but do add > > placeholder TODOs for where this could be added. > > > > The constructor change commits remove the non-default constructors for > > the 4 suppression types as they are antithetical to a table-driver > > parser where there are a large number of optional fields. > > I do really prefer that we keep recursive descent parsers in all the > parsers of the project. Why? Because they are the simplest parsers to > understand for someone who just wants to /debug/ it to fix things in the > way the parser. Yes, they are more verbose and the grammar handling is > hard coded. But that's a tradeoff I accept to keep the whole project as > "debuggable" as it can be, given the inherent complexity of the core > subject we are trying to tackle here. > > So, yeah, I am really not a fan for introducing a table-driven parser in > this context at this point. > Understood. I've mothballed this line of development (see https://sourceware.org/bugzilla/show_bug.cgi?id=3D19608#c3). If someone wants to try an alternative approach, they will at least get an idea of the scale of the changes needed. > > [...] > > Cheers, > Regards, Giuliano. > > -- > Dodji >