Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!burdvax!bbking!rmarks
From: rmarks@KSP.Unisys.COM (Richard Marks)
Newsgroups: comp.binaries.ibm.pc.d
Subject: UUDECODE 3.15
Message-ID: <716@bbking.KSP.Unisys.COM>
Date: 26 Sep 89 17:50:52 GMT
Organization: Unisys Corp. Knowledge Systems Projects
Lines: 43

As most of you have discovered.  My UUDECODE 3.07 cannot
handle the current postings.  The problem is a lowercase
character at the end of each encoded line.

When UUDECODE 3.07 sees the lowercase character, it assumes
the line is text not encoded data.  Until UUDECODE 3.15
is available, the fix is to remove this character.  Then
UUDECODE will give a bad section sum -r and size error.
The sum -r and size for the resultant output file will be
OK.

UUDECODE 3.15 will accept this type of encoded line.  It
also is 50% faster.  The speed up is because I recoded
about 5% of the code in ASM.  There is some moral here.

FLAME ON!
The idea behind UUENCODing is to get data over a minimal
communications line.  Such minimal lines may change lower
to upper case, squish down multiple blanks, and do other 
horrible things to data.  When UUDECODE 3.07 sees the lower
case, it assumes the file is corrupt and quits.  

Probably a bit severe, but the assumption is that lower case 
is never on an encoded line.  If there is some trivial corruption
then the user will not want to decode, but will want to
examine the file.  Well now I have a case where some UUENCODE
program is systematically putting lowercase in the file.

Note the first line has a 'z', the next a 'y', etc.  So 3.15
will check and validate this sequence.  There are so many
conditions with invalid sizes and counts that I was loath to accept
any line with lowercase at the end.  However I will enhance the
"-l" option to UUDECODE to permit this sort of line to get thru
with no line level checks. (Of course the sum -r and size checks
will still be valid on the file level.)

A better way would be for Rahul to use one of four other encoder's
that generate acceptable lines.
FLAME OFF!

Regards
Richard Marks
rmarks@KSP.unisys.COM