summaryrefslogtreecommitdiff
path: root/date.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2014-02-24 07:39:04 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-02-24 18:12:58 (GMT)
commitd4b8de0420ffcc7a654ddc6c69a96d3c1b25b4fa (patch)
tree8dbe700a87570f01daefd62dcf7f78b80b931d53 /date.c
parent7d9a2819415663ee5f0676d06cdbb1368fdc02c7 (diff)
downloadgit-d4b8de0420ffcc7a654ddc6c69a96d3c1b25b4fa.zip
git-d4b8de0420ffcc7a654ddc6c69a96d3c1b25b4fa.tar.gz
git-d4b8de0420ffcc7a654ddc6c69a96d3c1b25b4fa.tar.bz2
fsck: report integer overflow in author timestamps
When we check commit objects, we complain if commit->date is ULONG_MAX, which is an indication that we saw integer overflow when parsing it. However, we do not do any check at all for author lines, which also contain a timestamp. Let's actually check the timestamps on each ident line with strtoul. This catches both author and committer lines, and we can get rid of the now-redundant commit->date check. Note that like the existing check, we compare only against ULONG_MAX. Now that we are calling strtoul at the site of the check, we could be slightly more careful and also check that errno is set to ERANGE. However, this will make further refactoring in future patches a little harder, and it doesn't really matter in practice. For 32-bit systems, one would have to create a commit at the exact wrong second in 2038. But by the time we get close to that, all systems will hopefully have moved to 64-bit (and if they haven't, they have a real problem one second later). For 64-bit systems, by the time we get close to ULONG_MAX, all systems will hopefully have been consumed in the fiery wrath of our expanding Sun. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'date.c')
0 files changed, 0 insertions, 0 deletions