pg_base64_enc_len() and its clones overestimated the output
length by up to 2 bytes, as a result of sloppy thinking about
where to divide. No callers require a precise estimate, so
this has no consequences worse than palloc'ing a byte or two
more than necessary. We might as well get it right though.
This bug is very ancient, dating to commit
79d78bb26 which
added encode.c. (The other instances were presumably copied
from there.) Still, it doesn't quite seem worth back-ing.
Oleg Tselebrovskiy
Discussion: https://postgr.es/m/
f94da55286a63022150bc266afdab754@postgrespro.ru
/*
* 3 bytes will be converted to 4, linefeed after 76 chars
*/
- return (srclen + 2) * 4 / 3 + srclen / (76 * 3 / 4);
+ return (srclen + 2) / 3 * 4 + srclen / (76 * 3 / 4);
}
static unsigned
pg_base64_enc_len(const char *src, size_t srclen)
{
/* 3 bytes will be converted to 4, linefeed after 76 chars */
- return ((uint64) srclen + 2) * 4 / 3 + (uint64) srclen / (76 * 3 / 4);
+ return ((uint64) srclen + 2) / 3 * 4 + (uint64) srclen / (76 * 3 / 4);
}
static uint64
pg_b64_enc_len(int srclen)
{
/* 3 bytes will be converted to 4 */
- return (srclen + 2) * 4 / 3;
+ return (srclen + 2) / 3 * 4;
}
/*