Re: [PATCH 1/3] git_parse_unsigned: reject negative values
- From
Jeff King <peff@peff.net>
- Date
- Oct 21, 2022, 20:13 UTC
- Message-ID
- <Y1L9fF6yd9EIIp9e@coredump.intra.peff.net>
- In-Reply-To
- <9c8440e5e82777311c6217cb4a9ddcd5cb8ce689.1666359915.git.gitgitgadget@gmail.com>
On Fri, Oct 21, 2022 at 01:45:12PM +0000, Phillip Wood via GitGitGadget wrote:
Show 6 quoted lines
> 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