[DTrace-devel] [PATCH 3/4] test: Update some char-array results files
Eugene Loh
eugene.loh at oracle.com
Tue Jul 22 21:53:20 UTC 2025
On 7/22/25 09:51, Nick Alcock wrote:
> On 25 Mar 2025, eugene loh said:
>> From: Eugene Loh <eugene.loh at 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.
There might be other issues. There may be broader issues here about how
we should handle strings. But, I guess here we can focus on this patch.
> 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?
The 3a551bf patch made this test fail, but changing the .r file as
indicated works both for historical behavior and for this new patch
(modulo the 256/257 issue). So, "yes" to your "Or do you mean?"
question. Would a change of commit message wording get your R-b? I'm
not sure what to change since I thought it was evident from the patch
what was going on.
>> 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.)
More information about the DTrace-devel
mailing list