Jeff King <peff@xxxxxxxx> writes:
> I wondered if we could be a bit more clever with the definition of
> "struct option". Something like:
>
> diff --git a/parse-options.h b/parse-options.h
> index 38a33a087e..99c7ff466d 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -126,7 +126,10 @@ struct option {
> enum parse_opt_type type;
> int short_name;
> const char *long_name;
> - void *value;
> + union {
> + int *intp;
> + const char *strp;
> + } value;
> const char *argh;
> const char *help;
>
>
> which would let the compiler complain about the type mismatch (of course
> it can't help you if you assign to "intp" while trying to parse a
> string).
>
> Initializing the union from a compound literal becomes more painful,
> but:
>
> 1. That's mostly hidden behind OPT_INTEGER(), etc.
>
> 2. I think we're OK with named initializers these days. I.e., I think:
>
> { OPTION_INTEGER, 'f', "--foo", { .intp = &foo } }
>
> would work OK.
The side that actually use .vale would need to change for obvious
reasons, which may be painful, but I agree it would have easily
prevented the regression from happening in the first place.
Thanks for a food for thought.
