From: Petr Vorel <pvorel@suse.cz>
To: Wei Gao <wegao@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] getcwd01: Implement .test_variants
Date: Fri, 15 Dec 2023 20:47:51 +0100 [thread overview]
Message-ID: <20231215194751.GB67360@pevik> (raw)
In-Reply-To: <20231206105318.11832-1-wegao@suse.com>
Hi Wei,
> /*
> * DESCRIPTION
> - * Testcase to test that getcwd(2) sets errno correctly.
> - * 1) getcwd(2) fails if buf points to a bad address.
> - * 2) getcwd(2) fails if the size is invalid.
> - * 3) getcwd(2) fails if the size is set to 0.
> - * 4) getcwd(2) fails if the size is set to 1.
> - * 5) getcwd(2) fails if buf points to NULL and the size is set to 1.
> - *
> - * Expected Result:
> - * 1) getcwd(2) should return NULL and set errno to EFAULT.
> - * 2) getcwd(2) should return NULL and set errno to EFAULT.
> - * 3) getcwd(2) should return NULL and set errno to ERANGE.
> - * 4) getcwd(2) should return NULL and set errno to ERANGE.
> - * 5) getcwd(2) should return NULL and set errno to ERANGE.
> + * Testcase to test that getcwd() sets errno correctly.
We prefer to keep info about tested errno (you can write errno or errnos if they
are different for syscall into it).
* 1) getcwd(2) fails if buf points to a bad address (EFAULT)
* 2) getcwd(2) fails if the size is invalid (ERANGE)
> #include <errno.h>
> @@ -27,28 +16,68 @@
> #include "lapi/syscalls.h"
> static char buffer[5];
> -
> -static struct t_case {
> +struct getcwd_variants {
> + void (*getcwd)(char *buf, size_t size, int exp_err);
> char *buf;
> size_t size;
> int exp_err;
> -} tcases[] = {
> - {(void *)-1, PATH_MAX, EFAULT},
> - {NULL, (size_t)-1, EFAULT},
> - {buffer, 0, ERANGE},
> - {buffer, 1, ERANGE},
> - {NULL, 1, ERANGE}
> };
> +static void verify_getcwd_raw_syscall(char *buf, size_t size, int exp_err);
> +static void verify_getcwd(char *buf, size_t size, int exp_err);
> +
> +static struct getcwd_variants variants[] = {
> +#ifdef __GLIBC__
> + { .getcwd = verify_getcwd, .buf = NULL, .size = (size_t)-1, .exp_err = ENOMEM},
> + { .getcwd = verify_getcwd, .buf = NULL, .size = 1, .exp_err = ERANGE},
> +#endif
> + { .getcwd = verify_getcwd, .buf = (void *)-1, .size = PATH_MAX, .exp_err = EFAULT},
> + { .getcwd = verify_getcwd, .buf = buffer, .size = 0, .exp_err = EINVAL},
> + { .getcwd = verify_getcwd, .buf = buffer, .size = 1, .exp_err = ERANGE},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = buffer, .size = 0, .exp_err = ERANGE},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = (void *)-1, .size = PATH_MAX, .exp_err = EFAULT},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = NULL, .size = (size_t)-1, .exp_err = EFAULT},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = buffer, .size = 0, .exp_err = ERANGE},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = buffer, .size = 1, .exp_err = ERANGE},
> + { .getcwd = verify_getcwd_raw_syscall, .buf = NULL, .size = 1, .exp_err = ERANGE},
Well, this is works, but we don't use test variants this way. We define
.test_variants in struct tst_test. Please have look how getdents01.c for
example.
Why it's important (besides consistency of how we write tests)? We parse
test_variants in our documentation.
https://github.com/linux-test-project/ltp/releases/download/20230929/metadata.20230929.html
=> see metadata.html#test_variants in your locally downloaded file, or run:
cd metadata && make && chromium ../docparse/*.html
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-12-15 19:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 10:53 [LTP] [PATCH v1] getcwd01: Implement .test_variants Wei Gao via ltp
2023-12-15 19:47 ` Petr Vorel [this message]
2023-12-22 10:06 ` [LTP] [PATCH v2] " Wei Gao via ltp
2023-12-27 13:21 ` Petr Vorel
2023-12-27 14:48 ` Petr Vorel
2024-01-03 8:21 ` Cyril Hrubis
2024-01-03 8:44 ` Petr Vorel
2024-01-03 9:32 ` Wei Gao via ltp
2024-01-04 2:23 ` Wei Gao via ltp
2024-01-03 8:39 ` Wei Gao via ltp
2024-01-03 8:48 ` Petr Vorel
2024-01-04 2:40 ` [LTP] [PATCH v3] " Wei Gao via ltp
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=20231215194751.GB67360@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
--cc=wegao@suse.com \
/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