Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5629: base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-09-07 11:28:05
#5629: base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator
-------------------------------+---------------------------
Reporter: nen777w@⦠| Owner: ramey
Type: Bugs | Status: assigned
Milestone: To Be Determined | Component: serialization
Version: Boost 1.45.0 | Severity: Problem
Resolution: | Keywords:
-------------------------------+---------------------------
Comment (by prantlf@â¦):
The problem of padding could be solved by making the transform_width
stateful. If you want to encode/decode to/from BASE64 and you input comes
in chunks or as a stream, you need to save your previous state to be able
to continue with the next chunk correctly.
The transform_width currently goes "blindly" for the next item pointed to
by the iterator, although there may not be enough items to finish the
minimum quantum. It even ends up with buffer overflow, if your input
sequence is not zero-padded. Also, this eager reading of the zero padding
makes it useful only to convert once a complete buffer.
Having the transform_width "know" that there is a minimum quantum of units
to read which has to be available to produce an output unit, it would
prevent the buffer overflow and allow transforming chunked input.
I added the end-iterator and state to the transform_width (either directly
or to the transformed iterator by an iterator adaptor). Reading ahead and
storing the next value makes the code a little longer and note so compact.
Also, tt runs significantly slower than a hand-coded BASE64 encoder; I\m
nor sure why. Maybe copying of the iterators around?
Would it make sense to include a stateful transform_width in boost?
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/5629#comment:10> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:14 UTC