Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!rhesus!uwmacc!uwmcsd1!leah!albanycs!steinmetz!philabs!per
From: per@philabs.Philips.Com (Paul Rutter)
Newsgroups: comp.sources.d
Subject: Re: btoa/atob and tarmail/untarmail
Message-ID: <1208@briar.Philips.Com>
Date: Sat, 30-May-87 12:18:26 EDT
Article-I.D.: briar.1208
Posted: Sat May 30 12:18:26 1987
Date-Received: Tue, 2-Jun-87 00:37:38 EDT
References: <7702@orchid.UUCP> <1046@viper.Lynx.MN.ORG> <886@lll-lcc.aRpA> <1999@dg_rtp.UUCP>
Reply-To: per@briar.philips.com.UUCP (Paul Rutter)
Distribution: comp
Organization: Philips Laboratories, Briarcliff Manor, NY
Lines: 20


 >One thing to note about atob/btoa is that will append upto 3 (or 4?) null
 >bytes upon conversion from printable chars to binary.  Compress evidently
 >can handle it, but I was surprized when I was using them without compress.

As the original author of btoa/atob, I can say that this is NOT true.  If you
encode 3 binary bytes with btoa and decode with atob, you get the same 3
bytes out, no more.  (If you run something weird before btoa, then maybe that
is introducing word padding.)  (Anyway, if tarmail has survived MVS and VMS
routing, what more could you ask? -:} ).

(There is a byte count in the btoa encoding, and this is used to copy out the
right number of bytes from the tmp file used internally).

Since there may by now be bogus forms of btoa/atob around, I have reposted
the source to net.sources (this is identical, hopefully, to what the compress
people distribute, so if you have tarmail stuff from a compress distribution
do not worry).

						Paul Rutter