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

Eugene Loh
2025-07-22T21:53:27Z

On 7/22/25 09:51, Nick Alcock wrote:

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

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