Re: [RFC PATCH iproute2-next 2/2] dcb: add new subcommand for apptrust object

[Petr Machata <petrm@nvidia.com>]

<Daniel.Machon@microchip.com> writes:

> Den Fri, Sep 09, 2022 at 08:06:31AM -0700 skrev Stephen Hemminger:
>> [You don't often get email from stephen@networkplumber.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> 
>> On Fri, 9 Sep 2022 12:37:01 +0200
>> Daniel Machon <daniel.machon@microchip.com> wrote:
>> 
>> >       } else if (matches(*argv, "app") == 0) {
>> >               return dcb_cmd_app(dcb, argc - 1, argv + 1);
>> > +     } else if (matches(*argv, "apptrust") == 0) {
>> > +             return dcb_cmd_apptrust(dcb, argc - 1, argv + 1);
>> >       } else if (matches(*argv, "buffer") == 0) {
>> 
>> Yet another example of why matches() is bad.
>> 
>> Perhaps this should be named trust instead of apptrust.
>
> Hah, that slipped my mind.
>
> Obviously this wont do. Will have to come up with some different naming 
> in an eventual non-RFC patch.

Wait, this doesn't change anything, does it? "a", "ap" and "app"
previously referred to dcb_cmd_app, which they still do with the patch.
"appt" etc. were previously rejected, now refer to apptrust.

I've been known to miss issues in this area in the past, and for that
reason agree with the sentiment on matches(). But what problem does this
patch introduce?

And yeah, +1 for "trust".