Re: [PATCH] test-progress: fix test failures on big-endian systems

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.