parse-options: refactor human-friendly-integer parser out of pack-objectsjc/parse-options-humint

We only had code to understand unit suffixes such as g/m/k (as in
2g/400m/8k) in the configuration parser but not in the command line
option parser.  "git pack-objects" worked it around by having a
custom extension to the parse-options API; make it available to
other callers.

The new macro is not called OPT_ULONG() but OPT_HUM_ULONG(), as it
would be bizzarre to have ULONG that understands human friendly
units while INTEGER that does not.  It is not named with a shorter
"OPT_HULONG", primarily to avoid having to name a future parallel
for parsing human friendly integer "OPT_HINT".

Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 17 insertions, 0 deletions

diff --git a/parse-options.c b/parse-options.c
index c2cbca25cc..948ade7cea 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -136,6 +136,23 @@ static int get_value(struct parse_opt_ctx_t *p,
 			return opterror(opt, "expects a numerical value", flags);
 		return 0;
 
+	case OPTION_ULONG:
+		if (unset) {
+			*(unsigned long *)opt->value = 0;
+		} else if (opt->flags & PARSE_OPT_OPTARG && !p->opt) {
+			*(unsigned long *)opt->value = opt->defval;
+		} else if (get_arg(p, opt, flags, &arg)) {
+			return -1;
+		} else if (opt->flags & PARSE_OPT_HUMAN_NUMBER) {
+			if (!git_parse_ulong(arg, (unsigned long *)opt->value))
+				return opterror(opt, "expects a numerical value", flags);
+		} else {
+			*(unsigned long *)opt->value = strtoul(arg, (char **)&s, 10);
+			if (*s)
+				return opterror(opt, "expects a numerical value", flags);
+		}
+		return 0;
+
 	default:
 		die("should not happen, someone must be hit on the forehead");
 	}