Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!tekcrl!scott
From: scott@tekcrl.TEK.COM (Scott Huddleston)
Newsgroups: comp.sources.d
Subject: Re: help with compress on XENIX
Message-ID: <2157@tekcrl.TEK.COM>
Date: 16 Dec 87 22:02:29 GMT
References: <810@hyper.UUCP>
Reply-To: scott@tekcrl.UUCP (Scott Huddleston)
Organization: Tektronix Laboratories, Beaverton, OR.
Lines: 39
Keywords: compress,xenix,4.0,help
cc: scott


In article <810@hyper.UUCP> mark@hyper.UUCP (Mark Mendel) writes:
>I have recently tried to compile compress 4.0 on XENIX.
>
>The result is not compatible with BSD output.  Further, though it is able to
>uncompress correctly, the 'compressed' files seem to be larger.
>
>I'm sure it must be a bug that somebody has already fixed.  Please send mail.
>
>Compress -V output:
>
>$Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $
>Options: vax, BSD4_2, BITS = 16

Your problem sounds like the following.

A compressed file will have up to 7 unused bits in its last byte,
depending on how its final output code is aligned.

#if vax
	then the unused bits contain garbage
#else
	they are (properly) cleared
#endif

It's a disconcerting feature, in that it causes vax vs. non-vax compressed
to not "cmp" equal (usually), but not a functional bug:  a vax-compressed 
file will properly decompress on a non-vax, and vice versa.

I don't have a patch handy, but it's not hard to find and fix.

Identical files under different OS's often have different sizes if
measured in blocks (but identical sizes measured in chars).  This could
explain why your Xenix-compressed files seem larger.

P.S.- standard tar (from the BSD distribution) has a similar "bug": in a
tar image, the last data block for each file has unused bytes that
contain garbage.  A smarter tar clears the unused bytes.  Standard and
smart tar "untar" identically.  But "smart tar" images compress better
than "standard tar" images, often by 10%.