config: properly range-check integer values
commit42d194e95870a9eeea192789226b7d51b1c90c96
authorJeff King <peff@peff.net>
Sun, 8 Sep 2013 08:33:08 +0000 (8 04:33 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 9 Sep 2013 18:04:29 +0000 (9 11:04 -0700)
treeb6b9bd44b7a7973b0d30638b33685cd1bc4c5ba3
parent7192777d226c5b8653c65112a309c2ebd3d6d5c5
config: properly range-check integer values

When we look at a config value as an integer using the
git_config_int function, we carefully range-check the value
we get and complain if it is out of our range. But the range
we compare to is that of a "long", which we then cast to an
"int" in the function's return value. This means that on
systems where "int" and "long" have different sizes (e.g.,
LP64 systems), we may pass the range check, but then return
nonsense by truncating the value as we cast it to an int.

We can solve this by converting git_parse_long into
git_parse_int, and range-checking the "int" range. Nobody
actually cared that we used a "long" internally, since the
result was truncated anyway. And the only other caller of
git_parse_long is git_config_maybe_bool, which should be
fine to just use int (though we will now forbid out-of-range
nonsense like setting "merge.ff" to "10g" to mean "true",
which is probably a good thing).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config.c