Subject: Re: [PATCH 00/14] numparse module: systematically tighten up integer parsing

From: Junio C Hamano <[email-masked]>
Date: Tue, 24 Mar 2015 09:09:09 -0700

Junio C Hamano <[email-masked]> writes:

> Michael Haggerty <[email-masked]> writes:
>
>> It is easy to allow "--abbrev=+7"; I would just need to add NUM_PLUS to
>> those call sites. Should I do so?
>
> The more relevant question to ask from my point of view is why you
> need to "add" NUM_PLUS to "enable" it.  What valid reason do you
> have to forbid it anywhere?  Only because you do not accept it by
> default, you need to "add" to "enable".
>
>>> Why is it a problem to allow "git cmd --hexval=0x1234", even if "git
>>> cmd --hexval=1234" would suffice?
>>
>> In some cases we would like to allow that flexibility; in some cases
>> not. But the strtol()/strtoul() functions *always* allow it.
>
> The same issue.  Whare are these "some cases"?

And the same issue appears in the "leading whitespace" thing I did
not mention in the earlier part of your message I responded to. I
also notice you answered yourself that there may not be a valid
reason to forbid end-user supplied "0x" prefix to arguments we
expect an integer for in your other message.

In short, if it is not a clearly bogus input that indicates a typo
or something (e.g.  "--size=48l? did the user meant 48, 48k, or
48m?"), and if it is clear we can tell the user meant what the code
would naturally interpret as (e.g. "--hexval=0x1234"), why forbid
it?