Re: [boost] [serialization] Padding for base64 dataflow iterators ?

Subject: Re: [boost] [serialization] Padding for base64 dataflow iterators ?
From: Timothy Madden (terminatorul_at_[hidden])
Date: 2010-07-29 02:23:05

Robert Ramey wrote:
> Timothy Madden wrote:
>> Hello
>>
>> Could the documentation page for dataflow iterators in the
>> serialization library please state that:
>>
>> 1. using base64 iterators will /not/ add the padding '=' characters in
>> the encoded data, that are present in the canonical encoding in
>> RFC4648 (The Base16, Base32, and Base64 Data Encodings) ?
>>
>> 2. binary string to be encoded should be null-terminated, or the
>> iterators will not pad the input stream of bits with 0s to reach a
>> multiple of 6 bits, but rather use whatever bits follow after the last
>> encoded byte in memory ?
>>
>>
>> Just so the user knows she either has to ensure padding, or otherwise
>> she should not expect the result to exactly follow the RFC, and the
>> result might not be suitable for data interchange between
>> applications, etc ...
>>
>> Or maybe the examples could be changed to include padding, which would
>> be even better ... :)
> 
> or maybe even better tweak the iterator to do the padding or
> add a padding iterator which would do it.

I think the iterator-like design makes this impractical as the start 
iterator would also require the end address for construction. Or at 
least some container would need to be defined with the start and end 
addresses, that would then provide the start and end iterators.

But a note like:
        "To achieve the base64 canonical encoding (as per RFC4648) make
         sure the data to be encoded is followed by a zero byte, and
         also pad the result with '=' characters up to an encoded
         string length that is a multiple of 4 characters."
would be practical.

Thank you,
Timothy Madden