Re: [PATCH v1] cyclictest: Generate optstring dynamically from long_options

[Crystal Wood <crwood@redhat.com>]

On Sat, 2026-01-10 at 13:37 +0200, Costa Shulyupin wrote:

> diff --git a/src/include/opt.h b/src/include/opt.h
> new file mode 100644
> index 000000000000..4d01917be024
> --- /dev/null
> +++ b/src/include/opt.h
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +#pragma once
> +
> +#include <getopt.h>
> +
> +/*
> + * build_optstring - allocate and build optstring from long_options
> + *
> + * Free resulted optstring aftre use.
> + */

"Free resulting optstring after use"

> +char *build_optstring(const struct option *long_opts);
> diff --git a/src/lib/opt.c b/src/lib/opt.c
> new file mode 100644
> index 000000000000..d235788001d9
> --- /dev/null
> +++ b/src/lib/opt.c
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +#include <stdlib.h>
> +
> +#include "opt.h"
> +
> +char *build_optstring(const struct option *long_opts)
> +{
> +	char *opts = NULL;
> +	int n = 0;
> +
> +	for (int i = 0; long_opts[i].name; i++) {
> +		opts = realloc(opts, n + 4);

I realize this isn't going to be noticeable even if it ends up being a
copy each time, but linear realloc like this makes me twinge and think
of how just about every other language in common use would have a
readily available growable string implementation :-P

> +
> +		if (long_opts[i].flag || long_opts[i].val < 32 || long_opts[i].val > 127)
> +			continue;

What happens if the OPT enum grows beyond 32 entries?  It's already at
16.  Maybe start the enum at 0x100, and print an error if val is less
than that but not valid for getopt?

Why is the implementation (slightly) different here versus the rtla
patch?  We should probably use an enum in rtla instead of '4', '\1',
etc. as well.

-Crystal