Re: svn commit: r1902206 - /apr/apr/trunk/encoding/apr_base64.c

On Mon, Jul 25, 2022 at 12:43 PM Ruediger Pluem <[email protected]> wrote:
>
>
>
> On 6/23/22 8:49 PM, Ruediger Pluem wrote:
> >
> >
> > On 6/23/22 5:12 PM, [email protected] wrote:
> >> Author: ylavic
> >> Date: Thu Jun 23 15:12:47 2022
> >> New Revision: 1902206
> >
> >
> >> @@ -275,16 +284,17 @@ APR_DECLARE(int) apr_base64_encode_binar
> >>      }
> >>
> >>      *p++ = '\0';
> >> -    return (int)(p - encoded);
> >> +    return (unsigned int)(p - encoded);
> >>  }
> >>
> >>  APR_DECLARE(char *) apr_pbase64_encode(apr_pool_t *p, const char *string)
> >>  {
> >>      char *encoded;
> >> -    int l = strlen(string);
> >> +    apr_size_t len = strlen(string);
> >>
> >> -    encoded = (char *) apr_palloc(p, apr_base64_encode_len(l));
> >> -    apr_base64_encode(encoded, string, l);
> >> +    assert(len <= (apr_size_t)APR_INT32_MAX);
> >
> > Shouldn't this be INT_MAX or APR_BASE64_ENCODE_MAX?
>
> Any update on this comment? I guess INT_MAX or APR_INT32_MAX is mood given the result of the discussion in this thread, but it
> probably should be APR_BASE64_ENCODE_MAX?

Good point, r1904666.

>
> >
> >> +    encoded = (char *) apr_palloc(p, apr_base64_encode_len((int)len));
> >> +    apr_base64_encode(encoded, string, (int)len);
> >>
> >>      return encoded;
> >>  }


Regards;
Yann.