Re: [PATCH] test-progress: fix test failures on big-endian systems
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 21, 2019, 08:51 UTC
- Message-ID
- <xmqqftjmlbvb.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20191021032144.GB13083@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 34 quoted lines
> 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.