From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH RFC 3/3] selftests/nolibc: migrate vfprintf tests to new harness
Date: Thu, 16 Nov 2023 08:48:02 +0100 [thread overview]
Message-ID: <ZVXJMgly7/et8JAt@1wt.eu> (raw)
In-Reply-To: <20231115-nolibc-harness-v1-3-4d61382d9bf3@weissschuh.net>
On Wed, Nov 15, 2023 at 10:08:21PM +0100, Thomas Weißschuh wrote:
> Migrate part of nolibc-test.c to the new test harness.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> tools/testing/selftests/nolibc/nolibc-test.c | 74 +++++++++++-----------------
> 1 file changed, 28 insertions(+), 46 deletions(-)
>
> diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> index 6c1b42b58e3e..c0e7e090a05a 100644
> --- a/tools/testing/selftests/nolibc/nolibc-test.c
> +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> @@ -1039,10 +1039,13 @@ int run_stdlib(int min, int max)
> return ret;
> }
>
> -#define EXPECT_VFPRINTF(c, expected, fmt, ...) \
> - ret += expect_vfprintf(llen, c, expected, fmt, ##__VA_ARGS__)
> +#define ASSERT_VFPRINTF(c, expected, fmt, ...) \
> + enum RESULT res = assert_vfprintf(_metadata, c, expected, fmt, ##__VA_ARGS__); \
> + if (res == SKIPPED) SKIP(return); \
> + if (res == FAIL) FAIL(return);
Please enclose this in a "do { } while (0)" block when using more than
one statement, because you can be certain that sooner or later someone
will put an "if" or "for" above it. This will also avoid the double
colon caused by the trailing one.
> -static int expect_vfprintf(int llen, int c, const char *expected, const char *fmt, ...)
> +static enum RESULT assert_vfprintf(struct __test_metadata *_metadata, int c,
> + const char *expected, const char *fmt, ...)
> {
> int ret, fd;
> ssize_t w, r;
> @@ -1051,25 +1054,20 @@ static int expect_vfprintf(int llen, int c, const char *expected, const char *fm
> va_list args;
>
> fd = open("/tmp", O_TMPFILE | O_EXCL | O_RDWR, 0600);
> - if (fd == -1) {
> - result(llen, SKIPPED);
> - return 0;
> - }
> + if (fd == -1)
> + return SKIPPED;
>
> memfile = fdopen(fd, "w+");
> - if (!memfile) {
> - result(llen, FAIL);
> - return 1;
> - }
> + if (!memfile)
> + return FAIL;
Till now it looks easier and more readable.
> va_start(args, fmt);
> w = vfprintf(memfile, fmt, args);
> va_end(args);
>
> if (w != c) {
> - llen += printf(" written(%d) != %d", (int)w, c);
> - result(llen, FAIL);
> - return 1;
> + _metadata->exe.llen += printf(" written(%d) != %d", (int)w, c);
> + return FAIL;
> }
Here however I feel like we're already hacking internals of the test
system and that doesn't seem natural nor logical. OK I understand that
llen contains the lenght of the emitted message, but how should the
user easily guess that it's placed into ->exe.llen, and they may or may
not touch other fields there, etc ? Also the fact that the variable is
prefixed with an underscore signals a warning to the user that they
should not fiddle too much with its internals.
I'm seeing basically two possible approaches:
- one consisting in having a wrapper around printf() that transparently
sets the llen field in _metadata->exe. This at least offload this
knowledge from the user who can then just know they have to pass an
opaque metadata argument and that's all.
- one consisting in saying that such functions should not affect the
test's metadata themselves and that it ought to be the caller's job
instead. The function then only ought to return the printed length,
and will not need the metadata at all.
I tend to prefer the second option. In addition, you seem to be returning
only 3 statuses (ok/skip/fail) so returning a single composite value for
this is easy, e.g. (result | llen) with result made of macros only touching
the high bits. If in the future more returns are needed, either a larger
int or shift can be used, or we can then return pairs or structs.
Regards,
Willy
next prev parent reply other threads:[~2023-11-16 7:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-15 21:08 [PATCH RFC 0/3] selftests/nolibc: introduce new test harness Thomas Weißschuh
2023-11-15 21:08 ` [PATCH RFC 1/3] selftests/nolibc: add custom " Thomas Weißschuh
2023-11-16 7:16 ` Willy Tarreau
2023-11-16 14:39 ` Thomas Weißschuh
2023-11-15 21:08 ` [PATCH RFC 2/3] selftests/nolibc: migrate startup tests to new harness Thomas Weißschuh
2023-11-16 7:33 ` Willy Tarreau
2023-11-16 14:46 ` Thomas Weißschuh
2023-11-15 21:08 ` [PATCH RFC 3/3] selftests/nolibc: migrate vfprintf " Thomas Weißschuh
2023-11-16 7:48 ` Willy Tarreau [this message]
2023-11-16 14:51 ` Thomas Weißschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVXJMgly7/et8JAt@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox