From: René Scharfe Date: Sat, 28 Feb 2026 11:28:39 GMT Subject: Re: [PATCH v2 2/2] parseopt: check for duplicate long names and numerical options Message-ID: <7c221132-c2ac-4c6f-9d89-72677a74beb5@web.de> In-Reply-To: <20260228105849.GA3626520@coredump.intra.peff.net> On 2/28/26 11:58 AM, Jeff King wrote: > On Sat, Feb 28, 2026 at 10:19:16AM +0100, René Scharfe wrote: > >> +static void parse_options_check_harder(const struct option *opts) >> +{ >> + struct strset long_names = STRSET_INIT; >> + for (; opts->type != OPTION_END; opts++) { >> + if (opts->long_name) { >> + if (!strset_add(&long_names, opts->long_name)) >> + optbug(opts, "long name already used"); >> + } >> + } >> + BUG_if_bug("invalid 'struct option'"); >> + strset_clear(&long_names); >> +} > > I confirmed on my silly pathological case that invoking rev-parse with a > real option shows no slowdown, and we now pay the same 10ms cost to show > "-h". > > Your other email made me wonder how the sorted-array solution might > perform (patch below). It shaves off 2ms of those 10. Probably not worth > caring about for "-h" output (which is already spending another 5-10ms > to generate the output, versus a normal parse). Curious; sorting performs worse on my machine (Apple M1, 1 is 2cc719175, 2 is patch 2 v2, 3 is your patch on top): Benchmark 1: ./git_main rev-parse --parseopt -- -h