[DTrace-devel] [PATCH 3/4] test: Update some char-array results files

[Eugene Loh]

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.)