Re: base64 bug handling \r characters

I batched up my pending changes, the primary one is that I restored
the use of mimencode if it is present on the system.  The code to
use pure Tcl routines is still in there for those systems that don't
have metamail installed, but it'll be slow for large attachments.

>>>[email protected] said:
 > On Fri, 24 Sep 2004 16:37:50 PDT, Brent Welch said:
 > > If you are running out of CVS that doesn't use mimencode,
 > > then there were bugs in the I/O channel encoding that caused that.
 > > I fixed those.  I have also added code that uses mimencode if
 > > it is present, but I got tired of the long times dealing with
 > > attachments.  Ahh - looks like I haven't committed those, yet.
 > > But, the binary encoding fixes should be in.
 > 
 > I found 2 buglets (both fixed in CVS now)
 > 
 > 1) in lib/seditExtras.tcl, we needed an 'fconfigure $in -translation
 > binary'
 > (This was what was causing my missing \r characters).
 > 
 > 2) I also found&fixed a buglet in lib/base64.tcl - we *always* output a
 > multiple of 3 characters, even when dealing with the trailing '=' -
 > result
 > was that we'd either get it right, or add 1 or 2 binary nulls to the
 > end.
 > 
 > I've tested that if I send myself a .pdf file, the results of saving the
 > attachment are binary identical to the original .pdf.
 > 

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]