[Ace-users] [ace-bugs] Bug in ACE_Base64

[J.T. Conklin]

Krishnakumar B <kitty at dre.vanderbilt.edu> writes:
> Essentially the function ACE_Base64::decode() did three passes over the
> input string (once to calculate the amount of memory to allocate, once to
> calculate the length of the input string and once to actually do the
> decoding).  I don't know what I was thinking when I wrote it :-)
>
> So I think there are two way to fix it:
>
> 1. Make sure no one is using ACE_Base64::length() (it should have never
>    been a public method) and if so, remove it and
>    just put the loop inside ACE_Base64::decode() so that we only make two
>    passes over the input.
>
> 2. Keep ACE_Base64::length() as it is, but change ACE_Base64::decode() so
>    that we only make two passes over the input.
>
>> Please share your thoughts,
>
> Thanks a lot for your enhancement.  If you feel that the above paragraph is
> a small addition to make (especially option 2) to your existing patch,
> please add it along with your enhancement.

Hi Kitty,

I'll take ownership of getting the ACE_Base64 bug fixes / enhancements
into the repo. I think I'm going to do it in two passes.  The first to
add the is_chunked option to encode() and to ensure the final trailing
newline is appened in non-chunked mode.  The second to address the
inefficencies you've identified.  I'd like to see about precomputing
the lookup tables at the same time, similar to what we do for CRC
calculations, so that its in the shared/read-only data segment.  I'll
check in the first this evening, and get to the rest in the coming week.

One thing that suprised me that none of the Base64 APIs I looked at
(ACE, Java, Python, 4.4BSD) are really appropriate for encoding and
unbounded streams of data.  One use case where this would be useful is
in the processing of email attachements that you wouldn't want to, or
couldn't even fit in main memory, perhaps in the SMTP module of a
firewall.  It's been years since I've worked in that domain, so I'll
leave that enhancement to someone who has a need themselves.

    --jtc

-- 
J.T. Conklin