| Message ID | 9c8440e5e82777311c6217cb4a9ddcd5cb8ce689.1666359915.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | a few config integer parsing fixes | expand |
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Phillip Wood <phillip.wood@dunelm.org.uk> > > git_parse_unsigned() relies on strtoumax() which unfortunately parses > negative values as large positive integers. Fix this by rejecting any > string that contains '-' as we do in strtoul_ui(). I've chosen to treat > negative numbers as invalid input and set errno to EINVAL rather than > ERANGE one the basis that they are never acceptable if we're looking for > a unsigned integer. And the code now would reject something like "43-21" because it does not insist that "-" must be used for a sign, so it makes EINVAL doubly appropriate, I would think. In the original code, "43-21" would have been parsed as "43" (by strtoumax) followed by "-" (which is rejected by get_unit_factor() and yielded EINVAL, so this change would not change the behaviour for such an input, if we receive EINVAL when we see a "-". A devil's advocate would consider if we ever want to have a unit factor that has "-" in it (e.g. "10000e-3" == 10). I can buy it if we want to declare that it is not worth supporting. > Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> > --- > config.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/config.c b/config.c > index cbb5a3bab74..d5069d4f01d 100644 > --- a/config.c > +++ b/config.c > @@ -1193,6 +1193,11 @@ static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max) > uintmax_t val; > uintmax_t factor; > > + /* negative values would be accepted by strtoumax */ > + if (strchr(value, '-')) { > + errno = EINVAL; > + return 0; > + } > errno = 0; > val = strtoumax(value, &end, 0); > if (errno == ERANGE)
On Fri, Oct 21, 2022 at 01:45:12PM +0000, Phillip Wood via GitGitGadget wrote: > git_parse_unsigned() relies on strtoumax() which unfortunately parses > negative values as large positive integers. Fix this by rejecting any > string that contains '-' as we do in strtoul_ui(). I've chosen to treat > negative numbers as invalid input and set errno to EINVAL rather than > ERANGE one the basis that they are never acceptable if we're looking for > a unsigned integer. Certainly this seems like the right thing to do for a function parsing an unsigned value. It would be nice if we could demonstrate the visible effect with a test, though (and of course catch any later regressions). Sadly "git config" doesn't let you ask to parse an unsigned type. But we can find things in the core.* region that are parsed by default (and not likely to change, as they represent file/memory sizes). Like: git -c core.bigFileThreshold=-1 rev-parse which quietly passes before your patch, but fails after. It does make me wonder if anybody uses a negative value like this in the wild for "no limit", as it does what you might imagine currently (I get 2^64-1). -Peff
Jeff King <peff@peff.net> writes: > It does make me wonder if anybody uses a negative value like this in the > wild for "no limit", as it does what you might imagine currently (I get > 2^64-1). I vaguely recall complaints on the command line argument that used to take -1 to mean "practically unlimited" when its parsing got tightened. I wouldn't be surprised if we are making a new issue in the same category in the configuration file with this change. But we can switch to the signed variant when it becomes an issue, I guess.
diff --git a/config.c b/config.c index cbb5a3bab74..d5069d4f01d 100644 --- a/config.c +++ b/config.c @@ -1193,6 +1193,11 @@ static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max) uintmax_t val; uintmax_t factor; + /* negative values would be accepted by strtoumax */ + if (strchr(value, '-')) { + errno = EINVAL; + return 0; + } errno = 0; val = strtoumax(value, &end, 0); if (errno == ERANGE)