Junio C Hamano <[email protected]> writes:
> I actually do not think we mind git_parse_int(), git_parse_long(),
> and git_parse_uint() to complement git_parse_ulong(). I am not
> enthused by the "nonnegative-int" thing, though.
>
> Do we have enough cases where we want to use signed type and reserve
> negative value for our own internal use (e.g. "unspecified yet")?
> If not, a very generic git_config_int() with a caller specific range
> check wouldn't look _so_ bad.
>
> parallel_jobs = git_config_int(var, val);
> if (parallel_jobs < 0)
> some corrective action;
> return 0;
And of course, if we _do_ have many callsites where the caller wants
a sub-range of the range allowed by the underlying type, we can have
<T> git_config_<T>_bounded(var, val, <T> lb, <T> ub)
where T are the usual integral types and lb and ub are (inclusive)
lower and upper bounds. With that, Jonathan's non-negative-int
would fall out as a natural consequence:
parallel_jobs = git_config_int_bounded(var, val, 0, INT_MAX);
I vaguely recall that Michael Haggerty had a series to add and use
helpers to parse values of integral types and something like that
interface was suggested in the discussion; and it may even have used
a word better than "bounded".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
