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

Initializing the union from a compound literal becomes more painful,

  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,


Reply via email to