On 22 Jan 2017, at 13:02, b...@qqmail.nl wrote:
>
> That encoded[len] reference should use the same apr_base64_encode_len result
> as the first allocation, or the bas64 data is truncated.
I think you are right - but the other way round in this case - I was allocating
one byte too many. Fixed in
That encoded[len] reference should use the same apr_base64_encode_len result as
the first allocation, or the bas64 data is truncated.
Re: followups: I don’t see a reason for deprecating the separate encoder
functions, after adding the useful wrapper. There are enough good reasons why
applicatio
> On 19 Jan 2017, at 15:10, Graham Leggett wrote:
>
> On 19 Jan 2017, at 3:22 PM, Dirk-Willem van Gulik
> wrote:
>
>> Any reason we do not have such in APR-2 (as a compagnion to
>> apr_pbase64_encode) ?
>>
>> Dw.
>>
>>
>>
>> APR_DECLARE(char *) apr_pbase64_encode_binary(apr_pool_t *p, co
On 19 Jan 2017, at 3:22 PM, Dirk-Willem van Gulik wrote:
> Any reason we do not have such in APR-2 (as a compagnion to
> apr_pbase64_encode) ?
>
> Dw.
>
>
>
> APR_DECLARE(char *) apr_pbase64_encode_binary(apr_pool_t *p, const unsigned
> char *string, int len)
> {
>char *encoded;
>
>
