Review/comment needed for the new public java.util.Base64 class

[Michael Schierl]

Am 18.10.2012 04:10, schrieb Xueming Shen:
> Hi
> 
> Webrev has been updated with following changes
> 
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods

I think line 443 needs an additional check for atom == 0. Same for the
array case. At least if you do not want an endOfInput flag in the
parameters. If you have an endOfInput flag, you can use that in the
condition instead of atom == 0.

Consider this example where trying to encode 25 bytes using an input
ByteBuffer of 16 bytes and an output ByteBuffer of 32 bytes (Of course,
you'd use larger buffers in practice, but the same can happen with
larger buffers too, as long as your buffer size is not divisible by
three, or you do not completely fill the buffer with each read. Both can
happen if the media you are reading from uses a different sector/block
size - like when attaching a base64 attachment of a large file from disk
to an email).

First you fill 16 bytes of input into input buffer, then you call encode
the first time. it will encode the first 15 bytes to 20 bytes of output,
then encode the 16th byte to XY==. You flush the output and fill the
next 9 bytes into the input buffer. The next call to encode will encode
the 9 bytes to 12 bytes. So, in total you have 36 bytes, but the padding
is in the middle.

With the check, the first call will encode the first 15 bytes to 20
bytes of output and leave the 16th byte in the buffer. You flush the
output and load 9 bytes to the 1 remaining byte in the input buffer. The
second call will encode the first 9 bytes to 12 bytes and leave one byte
left over. You flush the buffer and call a third time, which will encode
the last byte to XY==. Still 36 bytes, this time with padding at the end.


Regards,


Michael