Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!noao!arizona!cjeffery
From: cjeffery@arizona.edu (Clinton Jeffery)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: lharc algorithm (was Re: Final Vote Tally/Summary)
Message-ID: <10184@megaron.arizona.edu>
Date: 11 Apr 89 20:51:37 GMT
References: <617@eecea.eece.ksu.edu>
Organization: U of Arizona CS Dept, Tucson
Lines: 21

From an article, by khc@eecea.eece.ksu.edu (Ken Carpenter):
complaining about lzhuf.c...
> On the 3B1 the resulting executable could compress, but dumped core when
> attempting to expand the compressed file... [not to mention]
> an extremely long compress time.  I compressed the same "core" file using
> 16bit "compress" and it went much more quickly.

Rather than assume a bug in the implementation, note that it was posted
for TURBO C only--I was able to get it to work fine on a VAX by changing
all the ints and unsigneds to shorts and unsigned shorts.

Don't assume a bug in an implementation when porting to a machine with
a different wordsize!!  The lzh algorithms are obviously superior to
what we have been using.  Your timing complaint is valid with respect
to lzhuf.c but not the lharc program.  Lzhuf.c spends more than half
its encoding time within a single routine, which suggests someone more
clever than I could speed it up without sacrificing portability...
-- 
| Clint Jeffery, University of Arizona Department of Computer Science
| cjeffery@arizona.edu -or- {noao allegra}!arizona!cjeffery
--