Re: [boost] [Boost-users] base 64 encoding

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-01-09 11:44:55

Look at this I see:

we have one byte 8 bits long.

transform_width should transform this in to "pieces" each 6 bits long.

So there are two choices.

return 1 6 bit piece and throw away 2 bits

or

return 2 6 bit pieces.  This would require 12 bits from the input.  Hence 
one
would have to feed it 2 bytes.

So that's why it requests 2 input bytes to produce 2 6 bit items.

So a couple of "solutions"

don't feed it it short strings.  (fast, only done at setup, but perhaps 
burdensome)

or

alter transformwidth so that requests beyond the end of the input(easy to 
use, but perhaps slower)

So I see that as the current situation.

Robert Ramey

Eames, Andrew wrote:
> I posted this on the boost users group but got no final answer - this
> looks like a bug to me or am I just using it incorrectly?
>
>  Andrew
>
>
>
> From: Eames, Andrew
> Sent: Friday, January 04, 2008 1:13 PM
> To: 'boost-users_at_[hidden]'
> Subject: Re: [Boost-users] base 64 encoding
>
>
>
> I must be missing something fundamental here. The following code
> fragment doesn't work (VC++ 8.0 SP1) - the checked iterators in STL
> catch walking off the end of the source - transform_width is
> attempting
> to access the second element of the vector
>
>
>
> typedef
>
>    base64_from_binary<
>
>        transform_width<vector<char>::const_iterator, 6, 8>
>
>        > base64_t;
>
>
>
>  vector<char> hippo(1);
>
>  string enc(base64_t(hippo.begin()), base64_t(hippo.end())); // ->
> checked iterator assertion fires
>
>
>
> In basic_text_oprimitive.ipp, the iterator is a pointer so it's
> possible
> it may be silently doing something bad
>
>  Andrew
>
>
>
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: Friday, January 04, 2008 11:58 AM
> To: boost-users_at_[hidden]
> Subject: [Spam:***** SpamScore] Re: [Boost-users] base 64 encoding
>
>
>
> Take a look at basic_text_oprimitive.ipp around line # 64.
>
>
>
> Note that I add "padding" here to address this problem.  Perhaps that
> is
> the missing
>
> magic.  Hmmm. perhaps that code should be part of the iterator.
>
>
>
> Also look at the code text_iterators_base64 in the serialization test
> suite.
>
>
>
> Robert Ramey
>
>
>
> "Eames, Andrew" <andrew_at_[hidden]> wrote in message
> news:8F37BF6F420455468C4BD57DD6BE199004C6146B_at_cobra.pc.cognex.com...
>
> But there is still the problem with running off the end of the
> source - If the source is not a multiple of 3 bytes then the input
> iterator will run off the end of the input sequence which can cause an
> error.
>
>   Andrew
>
>
>
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: Thursday, January 03, 2008 6:47 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] base 64 encoding
>
>
>
> I had to separately record the number of bytes.  Then when I
> decode, just pull off that number of bytes.
>
>
>
> Robert Ramey
>
>
>
> "Eames, Andrew" <andrew_at_[hidden]> wrote in message
> news:8F37BF6F420455468C4BD57DD6BE199004C613F8_at_cobra.pc.cognex.com...
>
> Hi,
>
> I'm trying to encode base64 data by composing
> base64_from_binary with transform_width but this doesn't appear to
> work correctly when the data is not a multiple of 3 long. What is the
> correct
> way to handle this  - do I have to handle the padding myself by
> extending the input data and then patching the tail of the result?
>
>    Thanks
>
>        Andrew
>
>
>
>
> ________________________________
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost