On 10/20/04 12:17 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
When I wrote the code for encoding/decoding base64 I didn't include the trailing "=" required by the standard defnition of base64. This was for a couple of reasons:
a) My de-serialization code didn't require the existence of "=" padding characters b) I didn't anticipate that the base64 text would be used by applications other than serialization c) I was short of time and had lots of other things to do.
We'll take a look at this for 1.33.
This looks like a potential bug in the making, so I don't think we should just punt on the issue until next time (especially if the time between releases continues to lengthen). This could lead to us and all other base-64 decoders after 1.32 is released to include code that forgives the lack of "=" symbols for "backwards compatibility with the 'broken from a standards perspective' base-64 encoder given in Boost 1.32". (In other words, we'll be _creating_ a situation like coding workarounds for broken compilers or coding HTML/CSS workarounds for broken compilers.) For what we could do: 1. Put a note in the serialization docs saying that its base-64 technique is private to itself and should _not_ be used in conjunction with outside code expecting to encode or decode standard base-64 data. 2. Fix the current base-64 code to match the outside standard [1] is quick-and-dirty and barely better than doing nothing. [2] would be the better overall fix. How long would it take to add "=" processing? If it's short enough, maybe the release could wait for it. (We've already used a lot of time between the 1.32 preparation announcement and the actual branch.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com