Re: base64 bug handling \r characters

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.

_______________________________________________
Exmh-workers mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/exmh-workers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBZ1kHcC3lWbTT17ARAlJEAJ9Gqbg6u7rK7joEiJpZaq6AJUoWQwCgnSwC
wCwLaBevIsySEWHsejR2Yqg=
=bClu
-----END PGP SIGNATURE-----