Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!linus!decvax!harpo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.sources
Subject: NEW - Bug in compress program (really C compiler)
Message-ID: <1145@utah-gr.UUCP>
Date: Tue, 17-Jul-84 13:22:51 EDT
Article-I.D.: utah-gr.1145
Posted: Tue Jul 17 13:22:51 1984
Date-Received: Wed, 18-Jul-84 06:55:51 EDT
Distribution: net
Organization: Univ of Utah CS Dept
Lines: 31

(This is a reposting with a fix in my original bug fix.)

Jim McKie (mcvax!jim) has uncovered what is apparently a bug in the C
compiler which causes the compress program to improperly compress large
files.  The calls to the output routine, coded as
	output( (code_int) ent->code );
cause sign extension of the code (oops).  Since they are declared as
unsigned ints, I can only assume that the C compiler is at fault here.
Unfortunately, code_int can't be declared as unsigned, since it is
necessary to pass a -1 to output().  His proposed fix is to recode the
statement as
	output( (code_int) ent->code & (maxmaxcode - 1) );
or
	output( (code_int) ent->code & ((1 << BITS) - 1) );

Another possibility is to declare code_int as unsigned, then instead of
passing -1 to output, to pass (1 << BITS) (also an illegal code).  I
haven't tested this possibility, but it seems as if it should work.
(It won't work on those C compilers which don't allow unsigned long, 
if BITS is >= 16.)

Also, another warning to those of you using pcc on a vax - do NOT
compile compress with -O unless you have installed the bug fix to c2
dealing with extv->cvtwl conversion.

=Spencer
(I hope I haven't lost anything for anyone.  Aren't you glad it doesn't
delete the original file, like compact does?)