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

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> Regarding specifically allowing/disallowing a leading '+': I saw a
> couple of callsites that explicitly check that the first character is a
> digit before calling strtol(). I assumed that is to disallow sign
> characters [1]. For example,
>
>     diff.c: optarg()

This one I know is from "if not a digit we know it is not a number";
it is not an attempt to say "we must forbid numbers to be spelled
with '+'", but more about "we do not need it and this is easier to
code without a full fledged str-to-num helper API" sloppiness.

>     builtin/apply.c: parse_num()

This parses "@@ -l,k +m,n @@@" after stripping the punctuation
around the numbers, so this is a valid reason why you would want an
optional feature "CANNOT_HAVE_SIGN" in the str-to-num parser and use
it.

>     maybe date.c: match_multi_number()

The approxidate callers parse random garbage input and attempt to
make best sense out of it, so they tend to try limitting the damage
caused by incorrect guesses by insisting "we do not consider +0 to
be zero" and such.  So this is a valid reason why you would want an
optional feature "CANNOT_HAVE_SIGN" in the str-to-num parser and use
it.

> I'm coming around to an alternate plan:
>
> Step 1: write a NUM_DEFAULT combination-of-options that gives the new
> functions behavior very like strtol()/strtoul() but without their insane
> features.
>
> Step 2: rewrite all callers to use that option (and usually endptr=NULL,
> meaning no trailing characters) unless it is manifestly clear that they
> are already trying to forbid some other features. This will already
> produce the largest benefit: avoiding overflows, missing error checking,
> etc.
>
> Steps 3 through ∞: as time allows, rewrite individual callsites to be
> stricter where appropriate.
>
> Hopefully steps 1 and 2 will not be too controversial.

All sounds sensible to me.