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?
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.
I didn't even try compiling to see how painful the fallout might be,
though.
-Peff
