On Thu, Sep 17, 2026 at 11:56:32AM +0200, Jonas Rebmann wrote:
> 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:
...
> > > > > 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":
I don't see the name is a big issue here, but okay, we can rename it.
> 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)
Yes.
> So there is no way how extending "strings" could test the code paths I
> want to test.
This is an open source, we can modify the loop to take the length into account.
Any string piece can be added to the end of it (just be located at the end of
the array. Also note, the combination of flags gives better coverage.
I'm not sure we need individual test cases in that sense. We may also add
something like printf() cases do, id est testing the result for all shortened
output buffers.
--
With Best Regards,
Andy Shevchenko
