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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-01-12 15:13:22 [-0600], Crystal Wood wrote:
> > --- /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

and assume you never run out of memory…

> > +
> > +		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.

GNU ARGP might be easier to parse and maintain in the long run
especially if 20 other options are added.
	https://www.gnu.org/software/libc/manual/html_node/Argp-Example-4.html

> -Crystal

Sebastian