Peter Samuelson <peter_at_p12n.org> writes:
> [Philip Martin]
>> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
>> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
>> @@ -410,7 +410,7 @@
>> /* Resize the stringbuf to make room for the (approximate) size of
>> output, to avoid repeated resizes later.
>> The optimizations in decode_line rely on no resizes being necessary! */
>> - svn_stringbuf_ensure(str, str->len + (len / 4) * 3 + 3);
>> + svn_stringbuf_ensure(str, str->len + (len / 4) * 3 + 4);
>>
>> while ( !*done && p < end )
>> {
>>
>> but I don't really understand the comment. There doesn't seem to be
>> anything "approximate" about this calculation?
>
> It is approximate because the encoded length is always a multiple of 4,
> even if the input length was not a multiple of 3. (This is why so many
> base64 strings end in = or ==; those are padding to a 4-byte output
> group.) The decoder doesn't yet know if the final group of 4 bytes
> will decode to 1, 2 or 3 bytes of plaintext.
I believe approximate is still wrong. It's supposed to be an accurate
calculation of the maximum output length. If some approximate value is
used and the output is longer than that then the code will crash.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-09 19:08:42 CET