Re: [PATCH 3/5] lib/tests: string_helpers: introduce test_string_unescape_one

[Jonas Rebmann <jre@pengutronix.de>]

On 2026-09-17 11:08, Andy Shevchenko wrote:
> On Thu, Sep 17, 2026 at 10:58:27AM +0200, Jonas Rebmann wrote:
>> On 2026-09-17 09:21, Andy Shevchenko wrote:
>>> On Wed, Sep 16, 2026 at 07:38:08PM +0200, Jonas Rebmann wrote:
>>>> The existing test_string_unescape() function follows a complex procedure
>>>> where it, given a set of UNESCAPE flags, appends multiple test fragments
>>>> and predicts their unescape result for the chosen set of flags. Rename
>>>> test_string_unescape() to a more descriptive
>>>> test_string_unescape_combined
>>>>
>>>> In preparation to add simple regression tests, introduce
>>>> test_string_unescape_one() which asserts on exactly one call to
>>>> string_unescape.
>>>>
>>>> Add some tests for corner cases which already pass.
>>>
>>> So, this is two-in-one patch change. Needs a split, but I'm not sure why
>>> we even need this. Can't your case be incorporated into the existing
>>> "combined" variant?
>>
>> They can not be incorporated into the combined variant because that
>> makes it impossible to control the size of the destination buffer. This
>> can not be fixed because the idea of the combined test is that all test
>> strings are combined into one buffer. The bugs fixed in this series only
>> occur when the destination buffer is limited.
> 
> We may modify the loop to provide the length of the destination buffer to be
> exactly what we expect, no?

The problem with test_string_unescape_combined is this array crudely
named "strings":

static const struct test_string strings[] = {
	{
		.in = "\\f\\ \\n\\r\\t\\v",
		.out = "\f\\ \n\r\t\v",
		.flags = UNESCAPE_SPACE,
	},

	...

it is not as one may expect a list of the individual tests which
string_unescape is subjected to.

Instead all of the in strings are concatenated and then string_unescape
is called on that for each possible set of flags:

string_unescape(\f\ \n\r\t\v\40\1\387\0064\05\040\8a\110\777\xv\xa\x2c\xD\x6f2\h\\\"\a\e\, out_real, 256, flags)

So there is no way how extending "strings" could test the code paths I
want to test.

-- 
Pengutronix e.K.                           | Jonas Rebmann               |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |