Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!pooh!madler
From: madler@pooh.caltech.edu (Mark Adler)
Newsgroups: comp.sys.handhelds
Subject: Re: Why ASC over UUENCODE?
Message-ID: <1991Feb14.015132.10732@nntp-server.caltech.edu>
Date: 14 Feb 91 01:51:32 GMT
References: <20148@shlump.nac.dec.com> <1991Feb13.101558.5056@lth.se> <59678@eerie.acsu.Buffalo.EDU>
Sender: news@nntp-server.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 21
Nntp-Posting-Host: pooh


James H. Cloos points out:
>> ASC includes a CRC, uuencode does not.

A *very* important point, but easily worked around, since the HP has a
BYTES command for checking just that sort of thing.  As for HP binary
objects generated outside the HP (like by an assembler), if they can
generate an ASC-> format, then they can just as easily compute the
result of BYTES (since ASC uses the same crc) for use with uuencode.

I believe the wide availability of uuencode/decode for many machines
(a fact apparently still disputed) makes it more portable than ASC which
is available on only one machine (the HP-48SX).  This is particularily
important when you want to save time and memory by doing a binary download
into your calculator.

One solution is to have a portable ->ASC-> converter, but why bother when
uu* is already in place, and is more efficient (by 50%) in mail bandwidth?

Mark Adler
madler@pooh.caltech.edu