From: Daniel Stenberg (Daniel.Stenberg@haxx.nu)
Date: Mon May 29 2000 - 04:21:15 CDT
As reported previously.
Andrew M. Bishop found an odd behaviour in the base64 decoding, as this mail
shows:
http://daniel.haxx.nu/hypermail/base64
As the person who added that silliness, I feel obliged to describe the nature
of this problem and suggest how to fix this:
Base64 converts I input octets to O output octets. The current parser wrongly
assumes that for each base64 encoded line in the mail, there is an even
number of I. Each line is decoded separately, as truely atomic units.
The Quoted-printable decoder reads following lines by itself in order to
circumvent this problem, but that is much easier done in QP-decoding since it
clearly marks at the end-of-line that a continuation is expected.
The base64 decoder can't easily read the following line by itself without
doing the function a lot hackish, since in order to know when the section is
ending, it would need to check each new line for the ending boundary-string.
It may be so that the only reasonable fix is to merge all base64 encoded
lines into a single large one and do the decode in one single shot. This is
of course bad memory wise since it demands that the entire base64-chunk *and*
the entire output-chunk are allocated simultaenously.
I think the nicest possible solution to this problem would be to add all the
detected base64-lines to a linked list, and when the end of the section is
found we write a function that extends the current base64decoder and decodes
all the lines in the list as one big base64-chunk.
I am willing to do this change, unless anyone else wants to or have a better
idea of how to correct this.
-- Daniel Stenberg - http://www.contactor.se/~dast - +46-705-44 31 77 ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol