From: Nick Alcock <nick.alcock@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Nick Alcock <nick.alcock@oracle.com>, <dtrace@lists.linux.dev>,
<dtrace-devel@oss.oracle.com>
Subject: Re: [PATCH] Need -w for destructive actions, even if clause is not used
Date: Tue, 22 Jul 2025 14:36:56 +0100 [thread overview]
Message-ID: <87bjpc5ouf.fsf@esperi.org.uk> (raw)
In-Reply-To: <f7a6a3e5-0c05-0b9c-d46b-1982b67e16fd@oracle.com> (Eugene Loh's message of "Thu, 17 Jul 2025 12:37:20 -0400")
On 17 Jul 2025, Eugene Loh outgrape:
> On 7/15/25 06:59, Nick Alcock wrote:
>
>> On 11 Jul 2025, eugene loh uttered the following:
>>> From: Eugene Loh <eugene.loh@oracle.com>
>>>
>>> If a clause includes a destructive action but -w is not used, dtrace
>>> should not start up, even if the clause is ignored (due to -Z).
>>> Solaris treated this as a runtime error. We should do the same.
>>>
>>> The test err.Z_no-w.sh was misguided and is replaced by a more
>>> direct test.
>>>
>>> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
>> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
>>
>> modulo one microscopic annoyance (I am not a real unix programmer, I
>> don't like creat() and think we shouldn't add more).
>
> Sorry, I don't know what you're asking for here.
"Name too short" :) referring to:
> > + int dt_havedest; /* have any destructive actions */
> > };
>
> A piteous plea: could we call this dt_have_destructive or something? We
> call destructive stuff "destructive", unabbreviated, everywhere else,
> this flag is only checked in *one place* and thus hardly need concision,
> and to me 'dest' always means 'destination' and thus causes a
> double-take every time I see it used for something else.
Anyway...
>>> + * This check should never fail since, if any action is
>> Grammar:
>>
>> This check should never fail, since if any action is
>
> I think I see what you're saying: separate the two phrases with a
> comma. But there is a big appositional phrase in there ("if any
> action is destructive and -w is not set") and I wanted to set it off
> with the commas. Maybe I'm wrong. Dunno.
I tried that -- it feels clumsier, since you definitely cannot set it
off with a comma but *not* set off the clause surrounding it (as you did
above).
>>> + * destructive and -w is not set, we should already have
>>> + * failed.
>>> + */
>> (but worth keeping anyway, I agree.)
--
NULL && (void)
next prev parent reply other threads:[~2025-07-22 13:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 4:40 [PATCH] Need -w for destructive actions, even if clause is not used eugene.loh
2025-07-15 10:59 ` Nick Alcock
2025-07-17 16:37 ` Eugene Loh
2025-07-22 13:36 ` Nick Alcock [this message]
2025-08-01 15:36 ` Kris Van Hees
2025-08-01 17:49 ` Kris Van Hees
2025-08-01 18:02 ` Eugene Loh
2025-08-01 18:19 ` Kris Van Hees
2025-08-01 18:15 ` Eugene Loh
2025-08-01 18:22 ` 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=87bjpc5ouf.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@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.