From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
igt-dev@lists.freedesktop.org
Cc: Gustavo Sousa <gustavo.sousa@intel.com>,
Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Petri Latvala <adrinael@adrinael.net>
Subject: Re: [PATCH i-g-t v3 07/10] runner: Fix use of newline on arguments
Date: Fri, 31 Jan 2025 10:21:33 +0100 [thread overview]
Message-ID: <9d00ce60-74a0-4392-87e8-9107a76e644d@linux.intel.com> (raw)
In-Reply-To: <20250130172149.3657144-8-lucas.demarchi@intel.com>
On 30.01.2025 18:21, Lucas De Marchi wrote:
> Currently there's no support for newlines on arguments passed to runner.
> However it's also a silent failure:
>
> # igt_runner --test-list '/tmp/test
> list2.txt' build/tests/ /tmp/results
>
> # head /tmp/results/metadata.txt
> disk_usage_limit : 0
> test_list : /tmp/test
> list2.txt
> name : results
> ...
>
> # ./build/runner/igt_resume /tmp/results
> [9840425.334900] All tests already executed.
> resume failed at generating results
> Done.
>
> Embedding a newline like this is very dubious for test-list, but it's
> used for e.g. hooks. In future we will add the command line to the
> metadata and possibly migrate the hooks, so add support for
> escaping/unescaping the string on save/restore.
>
> The method chosen is slightly different than the one used for hooks:
> instead of adding a escape char and keeping the char escaped, this just
> prefers using an hex representation of the char with a \x<HEX>h
> sequence. This makes it easier when unescaping since the reader can
> continue reading one line per iteration. In future this can also be
> adopted by the hooks or even migrating the hooks to use metadata.txt.
>
> For compatibility with previous parsing, it still prints "(null)" for
> NULL pointers: ideally there would be nothing printed to avoid the
> special case for this string.
>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> runner/settings.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/runner/settings.c b/runner/settings.c
> index 693c5484e..b527c01d9 100644
> --- a/runner/settings.c
> +++ b/runner/settings.c
> @@ -1052,10 +1052,79 @@ static bool serialize_hook_strs(struct settings *settings, int dirfd)
> return true;
> }
>
> +/*
> + * Serialize @s to @f, escaping '\' and '\n'. See unescape_str()
> + */
> +static void escape_str(const char *s, FILE *f)
> +{
> + if (!s) {
> + fputs("(null)", f);
> + return;
> + }
> +
> + while (*s) {
> + size_t len = strcspn(s, "\\\n");
> +
> + if (len > 0) {
> + fwrite(s, len, 1, f);
> + s += len;
> + }
> +
> + if (*s) {
> + fprintf(f, "\\x%xh", *s);
> + s++;
> + }
> + }
> +}
> +
> +/*
> + * Unescape a '\' and '\n': undo escape_str
Nit: there is a specific format for documenting new functions. I have the impression
that the arguments are not properly documented.
> + *
> + * Exacpe chars using the form '\x<hex>h' so they don't interfere with the line
> + * parser.
> + *
> + * Return the number of chars saved in buf and optionally
> + * the number of chars scanned in @n_src if that is non-nul.
> + */
> +static size_t unescape_str(char *buf, size_t *n_src)
> +{
> + size_t dst_len = 0;
> + char *s = buf;
> +
> + while (*s) {
> + char next = *(s + 1);
> +
> + if (*s != '\\') {
> + buf[dst_len++] = *s++;
> + } else if (*s == '\\' && next == 'x') {
> + s += 2;
> + buf[dst_len++] = strtoul(s, &s, 16);
> + if (*s != 'h') {
> + /* this shouldn't happen */
> + return 0;
> + }
> + s++;
> + } else {
> + return 0;
> + }
> + }
> +
> + buf[dst_len] = '\0';
> +
> + if (n_src)
> + *n_src = s - buf;
> +
> + return dst_len;
> +}
Have you considered json_tokener_parse() / json_object_get_string() ?
Glib' g_strescape () / g_strcompress() ? Not a fan of Glib,
but it is currently used anyway. Or even libcurl' curl_easy_escape() /
curl_easy_unescape()? Meson probes for the lib, but I did not see it in use.
My point being that it would be better to reuse instead of reinventing this
wheel. If you prefer to use your own, please add unit testing, I found at least
one issue:
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet (26)
Lorem \xZZh ipsum dolor sit amet
Lorem (0)
Lorem \x41h ipsum dolor sit amet
Lorem A ipsum dolor sit amet (32)
I guess you want to check strtoul() output for errors(can it cause an infinite
loop on error?), check buffer limits to prevent writing past allocated size,
and using error code such as -1 instead of failing with 0.
> +
> #define SERIALIZE_LINE(f, s, name, fmt) fprintf(f, "%s : " fmt "\n", #name, s->name)
> #define SERIALIZE_INT(f, s, name) SERIALIZE_LINE(f, s, name, "%d")
> #define SERIALIZE_UL(f, s, name) SERIALIZE_LINE(f, s, name, "%lu")
> -#define SERIALIZE_STR(f, s, name) SERIALIZE_LINE(f, s, name, "%s")
> +#define SERIALIZE_STR(f, s, name) do { \
> + fputs(#name " : ", f); \
> + escape_str(s->name, f); \
> + fputc('\n', f); \
> + } while (0)
> bool serialize_settings(struct settings *settings)
> {
> FILE *f;
> @@ -1171,6 +1240,12 @@ static char *parse_str(char **val)
> {
> char *ret = *val;
>
> + /*
> + * Unescaping a string is guaranteed to produce a string that is
> + * smaller or of the same size. Just modify it in place and leak the
> + * buffer
> + */
> + unescape_str(ret, NULL);
> *val = NULL;
>
> return ret;
next prev parent reply other threads:[~2025-01-31 9:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-30 17:21 [PATCH i-g-t v3 00/10] Add igt_runner's cmdline to results Lucas De Marchi
2025-01-30 17:21 ` [PATCH i-g-t v3 01/10] runner/settings: Fix code_coverage_script leak Lucas De Marchi
2025-01-30 17:21 ` [PATCH i-g-t v3 02/10] runner: Free settings at the end Lucas De Marchi
2025-01-30 17:21 ` [PATCH i-g-t v3 03/10] runner/settings: Deduplicate cleanup Lucas De Marchi
2025-01-30 17:21 ` [PATCH i-g-t v3 04/10] runner/settings: Use wrapper macros for each type Lucas De Marchi
2025-02-07 18:34 ` Gustavo Sousa
2025-01-30 17:21 ` [PATCH i-g-t v3 05/10] runner/settings: Match serialization to parse Lucas De Marchi
2025-02-07 19:13 ` Gustavo Sousa
2025-01-30 17:21 ` [PATCH i-g-t v3 06/10] runner/settings: Drop extra strdup Lucas De Marchi
2025-01-30 17:21 ` [PATCH i-g-t v3 07/10] runner: Fix use of newline on arguments Lucas De Marchi
2025-01-31 9:21 ` Peter Senna Tschudin [this message]
2025-01-31 15:58 ` Lucas De Marchi
2025-02-03 18:09 ` Lucas De Marchi
2025-02-07 20:15 ` Gustavo Sousa
2025-01-30 17:21 ` [PATCH i-g-t v3 08/10] runner/settings: Add helpers to serialize/parse array Lucas De Marchi
2025-02-07 20:26 ` Gustavo Sousa
2025-01-30 17:21 ` [PATCH i-g-t v3 09/10] runner/settings: Serialize command line Lucas De Marchi
2025-02-07 20:36 ` Gustavo Sousa
2025-02-07 20:41 ` Gustavo Sousa
2025-01-30 17:21 ` [PATCH i-g-t v3 10/10] runner/resultgen: Add cmdline to results.json Lucas De Marchi
2025-01-30 19:00 ` Kamil Konieczny
2025-01-30 19:17 ` Lucas De Marchi
2025-01-31 9:31 ` Peter Senna Tschudin
2025-01-31 12:16 ` Kamil Konieczny
2025-01-31 15:39 ` Lucas De Marchi
2025-01-30 19:12 ` ✓ Xe.CI.BAT: success for Add igt_runner's cmdline to results (rev3) Patchwork
2025-01-30 19:12 ` ✓ i915.CI.BAT: " Patchwork
2025-01-30 21:21 ` ✗ i915.CI.Full: failure " Patchwork
2025-01-30 22:06 ` ✓ Xe.CI.Full: success " Patchwork
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=9d00ce60-74a0-4392-87e8-9107a76e644d@linux.intel.com \
--to=peter.senna@linux.intel.com \
--cc=adrinael@adrinael.net \
--cc=gustavo.sousa@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=lucas.demarchi@intel.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