From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace-devel@oss.oracle.com, <dtrace@lists.linux.dev>
Subject: Re: [DTrace-devel] [PATCH 4/4] rawfbt: selectively allow return() in clauses
Date: Wed, 16 Jul 2025 12:08:26 +0100 [thread overview]
Message-ID: <87tt3cpf4l.fsf@esperi.org.uk> (raw)
In-Reply-To: <aHZ8cuwbgbqEXGmd@oracle.com> (Kris Van Hees's message of "Tue, 15 Jul 2025 12:06:10 -0400")
On 15 Jul 2025, Kris Van Hees uttered the following:
> On Tue, Jul 15, 2025 at 11:50:21AM +0100, Nick Alcock wrote:
>> On 15 Jul 2025, Kris Van Hees via DTrace-devel verbalised:
>> > +static int
>> > +fun_cmp(const allowed_fun_t *p, const allowed_fun_t *q) {
>> > + int rc;
>> > +
>> > + if (p->mod != NULL) {
>> > + if (q->mod == NULL)
>> > + return 1;
>> > + else {
>> > + rc = strcmp(p->mod, q->mod);
>> > + if (rc != 0)
>> > + return rc;
>> > + }
>> > + } else if (q->mod != NULL)
>> > + return -1;
>>
>> Ugh, that's quite tangled for how little it does :( can't think of a
>> nicer approach though.
>
> I am hoping that perhaps in time a lot more functions may allow this, plus if
> someone is going to make use of this feature for error injection they are
> likely to use it for multiple functions and then being able to use a hashtable
> rather than scanning the list multiple times is nicer.
It's not the hashtable I was whining about, just the comparison
function. The hashtable absolutely makes sense.
--
NULL && (void)
next prev parent reply other threads:[~2025-07-16 11:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 5:48 [PATCH 4/4] rawfbt: selectively allow return() in clauses Kris Van Hees
2025-07-15 10:50 ` [DTrace-devel] " Nick Alcock
2025-07-15 16:06 ` Kris Van Hees
2025-07-16 11:08 ` Nick Alcock [this message]
2025-07-15 21:22 ` Eugene Loh
2025-07-15 21:39 ` Kris Van Hees
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=87tt3cpf4l.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=kris.van.hees@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.