allocated, in the encrypting case, even if outlen is zero. While I
don't believe this can ever happen, it requires careful examination of
lots of code paths to figure it out. This change doesn't fix a
serious bug, but makes the analysis simple. Also, don't bother with
separate code paths for malloc vs realloc depending on the previous
values; we can just use realloc always.
Thanks to Domagoj Babic for pointing out the (false but
understandable) null-pointer problem.
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@19641
dc483132-0cff-0310-8789-
dd5450dbe970
int st;
unsigned int outlen = (len + 7) & (~7U);
- if (krem->writelen < outlen) {
- if (krem->writelen == 0) {
- krem->inbuf = (char*)malloc(outlen);
- krem->outbuf = (char*)malloc(outlen+8);
- } else {
- krem->inbuf = (char*)realloc(krem->inbuf, outlen);
+ if (krem->writelen < outlen || krem->outbuf == 0) {
+ krem->inbuf = (char*)realloc(krem->inbuf, outlen ? outlen : 1);
krem->outbuf = (char*)realloc(krem->outbuf, outlen+8);
- }
- if(!krem->inbuf || !krem->outbuf) { errno = ENOMEM; return -1; }
- krem->writelen = outlen;
+ if(!krem->inbuf || !krem->outbuf) { errno = ENOMEM; return -1; }
+ krem->writelen = outlen;
}
outlen = (len + 7) & (~7U);