Stefan Beller <sbeller@xxxxxxxxxx> writes:
>> int git_config_nonnegative_int(const char *name, const char *value)
>> {
>> int ret;
>> if (!git_parse_nonnegative_int(value, &ret))
>> die_bad_number(name, value);
>> return ret;
>> }
>>
>> allowing
>>
>> parallel_jobs = git_config_nonnegative_int(var, val);
>> return 0;
>
> And I thought we wanted to prevent inventing yet another helper?
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;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html