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'`olReceived on Tue 30 May 2000 12:16:02 AM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:12 AM GMT GMT