Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!dcl-cs!bath63!pes
From: pes@bath63.UUCP (Paul Smee)
Newsgroups: net.micro.atari16
Subject: Re: Lattice C and UUDECODE
Message-ID: <242@bath63.UUCP>
Date: Sun, 19-Oct-86 01:28:04 EDT
Article-I.D.: bath63.242
Posted: Sun Oct 19 01:28:04 1986
Date-Received: Fri, 17-Oct-86 23:59:15 EDT
References: <8609160140.AA10538@ucbvax.Berkeley.EDU>
Reply-To: pes@ux63.bath.ac.uk (Paul Smee)
Organization: Bath University, England
Lines: 24

I've found several problems with uudecode, which are caused by
the uuencoded file being munged by 'terminal handlers' enroute to me.
The symptoms sound like some I've seen complained about, specifically
that the file appears to decode, but bombs.  On looking at the files,
I found 2 different sorts of problem.

First, spurious 'control chars' get inserted in some cases.  In fact,
these appear to always be NULs (0x0) put in as 'delay padding' by
someones term handling software.

Second, trailing spaces get stripped.

It is fairly trivial to modify uudecode to ignore all control chars
(less that ASCII space) -- and harmless, as they should not be in
a uuencoded file.  Then, pad the line out to an arbitrarily large length
using spaces (I simply tack 64 spaces on the end, in my buffer, before
decoding a line).  Appending 64 spaces is crude and inelegant, I know, but
it insures that there will be enough in all circumstances, and is a much
simpler mod than actually looking to see how many are needed -- especially
since the line may contain as yet unprocessed control chars to be thrown away.

Since making these trivial changes I've had no problems with uudecoded fils.

Hope this helps someone...