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

From

Jeff King <peff@peff.net>

Date

Oct 21, 2019, 03:21 UTC

Message-ID

<20191021032144.GB13083@sigill.intra.peff.net>

In-Reply-To

<xmqq36fmor7o.fsf@gitster-ct.c.googlers.com>

On Mon, Oct 21, 2019 at 09:52:11AM +0900, Junio C Hamano wrote:

> I can sympathize, but I do not think it is worth inventing OPT_U64()
> or adding "int total_i" whose value is assigned to "u64 total" after
> parsing a command line arg with OPT_INTEGER() into the former.
> 
> Catching a pointer whose type is not "int*" passed at the third
> position of OPT_INTGER() mechanically may be worth it, though.
> Would Coccinelle be a suitable tool for that kind of thing?

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.

I didn't even try compiling to see how painful the fallout might be,
though.

-Peff