From: Dodji Seketeli <dodji@seketeli.org>
To: Giuliano Procida <gprocida@google.com>
Cc: libabigail@sourceware.org, kernel-team@android.com,
"Matthias Männich" <maennich@google.com>
Subject: Re: [PATCH v4 05/15] diff suppression: Fix handling of change kinds.
Date: Mon, 11 May 2020 19:53:02 +0200 [thread overview]
Message-ID: <86tv0mfjep.fsf@seketeli.org> (raw)
In-Reply-To: <CAGvU0H=6u4ZO-fp4oO5Xb4UDKL5GxwPDZDDB0FVaKgJRi8cwCg@mail.gmail.com> (Giuliano Procida's message of "Mon, 11 May 2020 16:47:57 +0100")
Giuliano Procida <gprocida@google.com> a écrit:
> The code and documentation should agree, certainly! If we stick to current
> implementation and documentation, I would feel better if the code noisily
> ignored rather than silently ignored such suppressions.
In general, I chose to avoid emitting user messages unless those are
emitted in well defined places like special "passes" that are meant for
analysis and reporting.
So rather than scathering user messages left and right everywhere, I'd
prefer we properly fix this issue by adding a (set of) pass(es) that
would walk the parsed ini file, analyse it and emit warnings or errors
as necessary.
I understand that you've proposed something in that regard at
https://sourceware.org/pipermail/libabigail/2020q2/002160.html, so I
think the discussion will happen there.
So the more I think about this, the less I am in favour of handling that
here.
[...]
>> > Two of the short-cut checks are in fact buggy, missing out the
>> > change_kind field.
>>
>> That's by design. You don't need to specify the change_kind property
>> for the suppress_type directive to work because that property it's
>> considered advanced.
>
> It's not that change_kind should be mandatory but that it should be one of
> the fields considered sufficient for the specification not to be
> ignored.
When I was assessing what property should be part of the sufficient set,
it didn't seem to me that change_kind should be in there (because it did
sound too easy to make it match a super-broad set of things to
suppress). The goal, in my mind is *NOT* to strive for minimalism or
orthogonality. To the contrary. I'd rather require some redundancy to
be sure user think about this twice. Because, again, it's super easy to
come up with false negatives otherwise.
Nevertheless if you think it should, then it's just a discussion to be
held. As a matter of fact, I am not dead opposed to it. So in the
grand scheme of things, I don't see this as bug.
> The tests as written are very confusing then. A comment in the .suppr files
> that only specify change_kind to say "this suppression will be ignored"
> would be useful. It was these tests that led me to believe the code should
> have included change_kind as one of the sufficient fields.
Fair enough.
[...]
> To give you my perspective...
>
> I have no idea what suppression specifications are being used in reality,
> so I am looking at things fairly abstractly. I see things through a
> mathematical viewpoint: a suppression is simply a predicate (function
> returning a truth value) on a type of object.
>
> libabigail supports multiple suppression specifications and ORs them
> together. Within each suppression specification, things are (mostly) ANDed
> together (and within ANDs there is some support for NOT as well via
> _not_regex properties). [c.f. DNF
> <https://en.wikipedia.org/wiki/Disjunctive_normal_form>]
>
> So the user can construct certain types of predicates. More generally, the
> predicates which always return true or always return false are perfectly
> valid mathematically. The always false one (never suppress) is
> constructible by supplying an empty OR - no predicates - and the always
> true one would logically be constructible by supplying an empty AND - a
> predicate with no properties. Treating empty AND as false is what I meant
> by "inconsistent".
>
> More practically though, what do we want to happen when the user does
> something bad? The current behaviour is to silently ignore.
Yes. The "silent" part of the behaviour was not meant to be engraved in
stone forever :-) I still want to add a semantic pass to handle that
separately.
> I think it would be more useful to generate warning messages.
Agreed.
[...]
>> So, in light of my explanations above, I'd prefer that we don't apply
>> this patch.
>
> Understood.
>
>> Does that make sense?
>
> I can preserve the existing behaviours, but I would really want to do both
> of:
>
> a) comment the tests that were surprising to me (or allow change_kind as a
> sufficient property)
Agreed.
> b) emit warnings to the user whenever a suppression is going to be ignored
> because it doesn't have one of a list of properties
I am not opposed to this, but as I said above, I'd rather see this
happen as part of the separate discussion/project I mentioned earlier.
> I'm happy to adapt the code and repost.
I'd happily accept a patch that does a/ in this context.
I hope this helps.
Cheers,
--
Dodji
next prev parent reply other threads:[~2020-05-11 17:53 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 15:44 [PATCH 00/21] Simplify regex and suppression parsing Giuliano Procida
2020-04-23 15:44 ` [PATCH 01/21] Move regex definitions to own files Giuliano Procida
2020-04-23 15:44 ` [PATCH 02/21] Move libxml bits out of abg-sptr-utils.h Giuliano Procida
2020-04-23 15:44 ` [PATCH 03/21] Simplify generation of symbol whitelist regex Giuliano Procida
2020-04-23 15:44 ` [PATCH 04/21] Escape names used in symbol whitelisting regex Giuliano Procida
2020-04-23 15:44 ` [PATCH 05/21] abg-suppression.cc: More uniform variable naming Giuliano Procida
2020-04-23 15:44 ` [PATCH 06/21] diff suppression: Fix handling of change kinds Giuliano Procida
2020-04-23 15:44 ` [PATCH 07/21] Add POSIX regex wrapper functions Giuliano Procida
2020-04-23 18:07 ` [PATCH v2 " Giuliano Procida
2020-04-23 15:44 ` [PATCH 08/21] Use regex::compile wrapper instead of regcomp Giuliano Procida
2020-04-23 15:44 ` [PATCH 09/21] Use regex::match wrapper instead of regexec Giuliano Procida
2020-04-23 18:02 ` [PATCH v2 " Giuliano Procida
2020-04-23 15:44 ` [PATCH 10/21] Refactor read_parameter_spec_from_string logic Giuliano Procida
2020-04-23 15:44 ` [PATCH 11/21] Compile suppression regexes earlier Giuliano Procida
2020-04-23 15:44 ` [PATCH 12/21] Reduce direct access to suppression priv_ members Giuliano Procida
2020-04-23 15:44 ` [PATCH 13/21] Move match methods from priv to suppression_base Giuliano Procida
2020-04-23 15:44 ` [PATCH 14/21] Remove suppression types' priv class methods Giuliano Procida
2020-04-23 15:44 ` [PATCH 15/21] abg-suppression.cc: More consistent regex matching Giuliano Procida
2020-04-23 15:44 ` [PATCH 16/21] abg-tools-utils.cc: Assert generated regexes OK Giuliano Procida
2020-04-23 15:44 ` [PATCH 17/21] Refactor suppression property string parsing Giuliano Procida
2020-04-23 15:44 ` [PATCH 18/21] Refactor suppression property regex parsing Giuliano Procida
2020-04-23 15:44 ` [PATCH 19/21] Warn if user-supplied regexes fail to compile Giuliano Procida
2020-04-23 18:04 ` [PATCH v2 " Giuliano Procida
2020-04-23 15:44 ` [PATCH 20/21] Default construct suppression types Giuliano Procida
2020-04-23 15:44 ` [PATCH 21/21] Remove unused suppression type priv constructors Giuliano Procida
2020-04-23 18:11 ` [PATCH 00/21] Simplify regex and suppression parsing Giuliano Procida
2020-04-24 8:54 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 00/21]Simplify " Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 01/21] Move regex definitions to own files Giuliano Procida
2020-04-27 10:52 ` Matthias Maennich
2020-04-29 14:19 ` Dodji Seketeli
2020-04-29 14:35 ` Giuliano Procida
2020-05-04 9:19 ` Dodji Seketeli
2020-04-24 9:21 ` [PATCH v3 02/21] Move libxml bits out of abg-sptr-utils.h Giuliano Procida
2020-04-27 10:53 ` Matthias Maennich
2020-04-29 14:30 ` Dodji Seketeli
2020-05-04 9:20 ` Dodji Seketeli
2020-04-24 9:21 ` [PATCH v3 03/21] Simplify generation of symbol whitelist regex Giuliano Procida
2020-04-27 11:01 ` Matthias Maennich
2020-04-27 15:31 ` Giuliano Procida
2020-05-04 9:20 ` Dodji Seketeli
2020-04-24 9:21 ` [PATCH v3 04/21] Escape names used in symbol whitelisting regex Giuliano Procida
2020-04-27 11:14 ` Matthias Maennich
2020-04-27 15:37 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 05/21] abg-suppression.cc: More uniform variable naming Giuliano Procida
2020-04-27 11:17 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 06/21] diff suppression: Fix handling of change kinds Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 07/21] Add POSIX regex wrapper functions Giuliano Procida
2020-04-27 11:23 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 08/21] Use regex::compile wrapper instead of regcomp Giuliano Procida
2020-04-27 11:34 ` Matthias Maennich
2020-04-27 16:01 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 09/21] Use regex::match wrapper instead of regexec Giuliano Procida
2020-04-27 11:38 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 10/21] Refactor read_parameter_spec_from_string logic Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 11/21] Compile suppression regexes earlier Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 12/21] Reduce direct access to suppression priv_ members Giuliano Procida
2020-04-27 11:54 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 13/21] Move match methods from priv to suppression_base Giuliano Procida
2020-04-27 11:55 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 14/21] Remove suppression types' priv class methods Giuliano Procida
2020-04-27 11:57 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 15/21] abg-suppression.cc: More consistent regex matching Giuliano Procida
2020-04-27 12:07 ` Matthias Maennich
2020-04-27 16:18 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 16/21] abg-tools-utils.cc: Assert generated regexes OK Giuliano Procida
2020-04-27 12:08 ` Matthias Maennich
2020-04-27 16:21 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 17/21] Refactor suppression property string parsing Giuliano Procida
2020-04-27 12:17 ` Matthias Maennich
2020-04-27 16:42 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 18/21] Refactor suppression property regex parsing Giuliano Procida
2020-04-27 14:55 ` Matthias Maennich
2020-04-27 16:59 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 19/21] Warn if user-supplied regexes fail to compile Giuliano Procida
2020-04-27 15:36 ` Matthias Maennich
2020-05-01 8:49 ` Giuliano Procida
2020-04-24 9:21 ` [PATCH v3 20/21] Default construct suppression types Giuliano Procida
2020-04-27 15:40 ` Matthias Maennich
2020-04-24 9:21 ` [PATCH v3 21/21] Remove unused suppression type priv constructors Giuliano Procida
2020-04-27 15:41 ` Matthias Maennich
2020-05-04 12:34 ` [PATCH v4 00/15] Simplify regex and suppression parsing Giuliano Procida
2020-05-04 12:34 ` [PATCH v4 01/15] Tidy #includes in a few files Giuliano Procida
2020-05-04 12:49 ` Matthias Maennich
2020-05-11 13:24 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 02/15] Document ^_^ regex in generate_from_strings Giuliano Procida
2020-05-04 12:49 ` Matthias Maennich
2020-05-11 13:32 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 03/15] Escape names used in symbol whitelisting regex Giuliano Procida
2020-05-04 12:57 ` Matthias Maennich
2020-05-04 16:45 ` [PATCH v5 " Giuliano Procida
2020-05-11 13:59 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 04/15] abg-suppression.cc: More uniform variable naming Giuliano Procida
2020-05-11 14:04 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 05/15] diff suppression: Fix handling of change kinds Giuliano Procida
2020-05-04 13:04 ` Matthias Maennich
2020-05-11 14:15 ` Dodji Seketeli
2020-05-11 15:47 ` Giuliano Procida
2020-05-11 17:53 ` Dodji Seketeli [this message]
2020-05-12 9:54 ` Giuliano Procida
2020-05-12 10:14 ` [PATCH v5 05/15] Tidy checks for sufficient suppression properties Giuliano Procida
2020-05-12 16:11 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 06/15] Add POSIX regex wrapper functions Giuliano Procida
2020-05-11 16:37 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 07/15] Use regex::compile wrapper instead of regcomp Giuliano Procida
2020-05-11 16:38 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 08/15] Use regex::match wrapper instead of regexec Giuliano Procida
2020-05-12 16:35 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 09/15] Refactor read_parameter_spec_from_string logic Giuliano Procida
2020-05-13 7:51 ` Dodji Seketeli
2020-05-04 12:34 ` [PATCH v4 10/15] Compile suppression regexes earlier Giuliano Procida
2020-05-04 13:14 ` Matthias Maennich
2020-05-13 8:07 ` Dodji Seketeli
2020-05-13 15:36 ` Giuliano Procida
2020-05-04 12:34 ` [PATCH v4 11/15] Reduce direct access to suppression priv_ members Giuliano Procida
2020-05-04 12:34 ` [PATCH v4 12/15] Move match methods from priv to suppression_base Giuliano Procida
2020-05-04 12:34 ` [PATCH v4 13/15] Remove suppression type priv class methods Giuliano Procida
2020-05-04 12:34 ` [PATCH v4 14/15] abg-suppression.cc: More consistent regex matching Giuliano Procida
2020-05-04 13:17 ` Matthias Maennich
2020-05-04 12:34 ` [PATCH v4 15/15] abg-tools-utils.cc: Assert generated regexes OK Giuliano Procida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86tv0mfjep.fsf@seketeli.org \
--to=dodji@seketeli.org \
--cc=gprocida@google.com \
--cc=kernel-team@android.com \
--cc=libabigail@sourceware.org \
--cc=maennich@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).