Re: [PATCH 00/14] numparse module: systematically tighten up integer parsing
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 24, 2015, 16:09 UTC
- Message-ID
- <xmqq1tke8jiy.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <xmqq619q8k0h.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 17 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> 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?