From: Nick Alcock <nick.alcock@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 3/4] test: Update some char-array results files
Date: Tue, 22 Jul 2025 14:51:45 +0100 [thread overview]
Message-ID: <87wm8072q6.fsf@esperi.org.uk> (raw)
In-Reply-To: <20250325222521.15224-3-eugene.loh@oracle.com> (eugene loh's message of "Tue, 25 Mar 2025 18:25:20 -0400")
On 25 Mar 2025, eugene loh said:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> A few tests started failing with commit 3a551bfd
> ("trace: fix char-array handling"). Update the results files to
> reflect older behavior, whether on Solaris or with the legacy
> Linux DTrace implementation.
I think this commit didn't get reviewed because nobody understood what
this meant. If tests started failing, why adjust the results to reflect
*older* behaviour (presumably "before that change"?)
Or do you mean that commit 3a551bfd adjusted trace() to work like it
historically did, but one test was missed and needs correspondingly
adjusting?
> Notice that test/unittest/funcs/substr/tst.substr-large-idx.d
> specifies strsize=256. The older behavior would result in 256
> chars being shown. We add a results file that includes a 257th
> char.
(the trailing NUL, presumably.)
next prev parent reply other threads:[~2025-07-22 13:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 22:25 [PATCH 1/4] Remove orphaned dtrace_recdesc_t component dtrd_uarg eugene.loh
2025-03-25 22:25 ` [PATCH 2/4] test: Skip trace() of a 1-byte struct eugene.loh
2025-07-22 13:46 ` Nick Alcock
2025-08-13 20:20 ` Eugene Loh
2025-03-25 22:25 ` [PATCH 3/4] test: Update some char-array results files eugene.loh
2025-07-22 13:51 ` Nick Alcock [this message]
2025-07-22 21:53 ` Eugene Loh
2025-03-25 22:25 ` [PATCH 4/4] Pad strings in the output buffer with NUL bytes after terminating byte eugene.loh
2025-07-22 14:05 ` Nick Alcock
2025-04-11 20:38 ` [PATCH 1/4] Remove orphaned dtrace_recdesc_t component dtrd_uarg 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=87wm8072q6.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.