summaryrefslogtreecommitdiff
path: root/imap-send.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2016-02-22 22:44:28 (GMT)
committerJunio C Hamano <gitster@pobox.com>2016-02-22 22:51:09 (GMT)
commit3733e6946465d4a3a1d89026a5ec911d3af339ab (patch)
tree687aa6252267a70f503904d635f44600eb3bfae7 /imap-send.c
parentb32fa95fd8293ebfecb2b7b6c8d460579318f9fe (diff)
downloadgit-3733e6946465d4a3a1d89026a5ec911d3af339ab.zip
git-3733e6946465d4a3a1d89026a5ec911d3af339ab.tar.gz
git-3733e6946465d4a3a1d89026a5ec911d3af339ab.tar.bz2
use xmallocz to avoid size arithmetic
We frequently allocate strings as xmalloc(len + 1), where the extra 1 is for the NUL terminator. This can be done more simply with xmallocz, which also checks for integer overflow. There's no case where switching xmalloc(n+1) to xmallocz(n) is wrong; the result is the same length, and malloc made no guarantees about what was in the buffer anyway. But in some cases, we can stop manually placing NUL at the end of the allocated buffer. But that's only safe if it's clear that the contents will always fill the buffer. In each case where this patch does so, I manually examined the control flow, and I tried to err on the side of caution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'imap-send.c')
-rw-r--r--imap-send.c5
1 files changed, 2 insertions, 3 deletions
diff --git a/imap-send.c b/imap-send.c
index 4d3b773..2c52027 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -892,12 +892,11 @@ static char *cram(const char *challenge_64, const char *user, const char *pass)
response = xstrfmt("%s %s", user, hex);
resp_len = strlen(response) + 1;
- response_64 = xmalloc(ENCODED_SIZE(resp_len) + 1);
+ response_64 = xmallocz(ENCODED_SIZE(resp_len));
encoded_len = EVP_EncodeBlock((unsigned char *)response_64,
(unsigned char *)response, resp_len);
if (encoded_len < 0)
die("EVP_EncodeBlock error");
- response_64[encoded_len] = '\0';
return (char *)response_64;
}
@@ -1188,7 +1187,7 @@ static void lf_to_crlf(struct strbuf *msg)
j++;
}
- new = xmalloc(j + 1);
+ new = xmallocz(j);
/*
* Second pass: write the new string. Note that this loop is