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

[Jonas Rebmann]

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    |