[DTrace-devel] [PATCH] test: Suppress some white space

[Nick Alcock]

On 23 Jun 2025, Eugene Loh outgrape:

> On 6/13/25 10:10, Nick Alcock wrote:
>
>> On 9 Jun 2025, eugene loh spake thusly:
>>
>>> From: Eugene Loh <eugene.loh at oracle.com>
>>>
>>> The test suite turns pointers into "{ptr}" so that results
>>> comparisons will not be sensitive to particular pointer offset
>>> values.
>>>
>>> If these offsets change in width -- say, from 0xf0 to 0x100 --
>>> the amount of white space in the postprocessed output can change.
>>>
>>> Add additional postprocessing to a test that sometimes fails due
>>> to this problem.
>> Hmm... this would work for this test, but maybe we should change the
>> {ptr} substitution in runtest.sh itself so that it gets this right in
>> the general case?
>>
>> Something like
>>
>> diff --git a/runtest.sh b/runtest.sh
>> index 156e7dec8a1c3..c5703a81bc6d4 100755
>> --- a/runtest.sh
>> +++ b/runtest.sh
>> @@ -509,7 +509,7 @@ postprocess()
>>       # TODO: may need adjustment or making optional if scripts emit hex
>>       # values which are not continuously variable.
>>   -    sed -e '/^==[0-9][0-9]*== /!s,0x[0-9a-f][0-9a-f]*,{ptr},g' \
>> +    sed -e '/^==[0-9][0-9]*== /!s,0x[0-9a-f][0-9a-f]*\([ \t]*\),{ptr}\1,g' \
>>   	-e 's,at BPF pc [1-9][0-9]*,at BPF pc NNN,' < $tmpdir/pp.out > $final
>>         return $retval
>>
>> might work. (Obviously the lines would no longer line up, but the number
>> of spaces would remain the same as they were before the substitution.)
>>
>> Lots and lots of expected results would need regenerating after this,
>> of course...
>
> I agree that one can make a case for a broader change, but I'm not convinced that that would be the better way.  FWIW, there were
> these two commits
>         6f398f229 test: Make tests more resilient to different prid widths
>         72a79b784 test: Improve resilience of tests to ptr widths
> that took the narrower, more tactical approach to such a problem.
>
> I vote for the expedient route:  a "Reviewed-by" and we move on. But then, in this case, my vote doesn't count!

I think doing the narrow approach for now makes sense, but doing the
wider one makes more sense in future :) I tried and it's a nest of
thorns, though, unlike hex number replacement there are many places
where we don't want to totally ignore the amount of whitespace in use.
So...

Reviewed-by: Nick Alcock <nick.alcock at oracle.com>

-- 
NULL && (void)