Re: [PATCH 2/2] parseopt: check for duplicate long names and numerical options

From: Jeff King <peff@peff.net>
Date: Feb 27, 2026, 22:50 UTC
Message-ID: <20260227225055.GC2956443@coredump.intra.peff.net>
In-Reply-To: <7693799a-91a2-480a-ae3e-29f8eed5b55a@web.de>

On Fri, Feb 27, 2026 at 08:27:02PM +0100, René Scharfe wrote:

> The check clearly has a cost, but I have a hard time measuring it.
> We already do lots of (kinda cheap) checks.  Turning them on only
> in DEVELOPER builds (and ideally demonstrating a speedup) left as
> an exercise for interested readers (with stronger benchmark-fu)..

I agree it is probably not introducing a measurable slowdown. If we were to make it conditional, I'd suggest a run-time toggle (so we could turn it on for all test scripts, but not regular use).

That said...

Show 9 quoted lines

> @@ -655,6 +658,16 @@ static void parse_options_check(const struct option *opts)
>  			else if (short_opts[opts->short_name]++)
>  				optbug(opts, "short name already used");
>  		}
> +		if (opts->long_name) {
> +			if (strset_contains(&long_names, opts->long_name))
> +				optbug(opts, "long name already used");
> +			strset_add(&long_names, opts->long_name);
> +		}

...if you want to micro-optimize, note that the return value of strset_add() tells you whether the item was already in the set. That can save one hash of the string.

Probably the allocation for each element is the dominating cost, though, and it doesn't help with that.

-Peff