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