Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.bbs-scene.org!macgui.com!marklim
From: Mark P M Lim <marklim@macgui.com>
Newsgroups: comp.sys.apple2.programmer
Subject: RE: LZW decompressor
Date: Sat, 23 Nov 2013 02:31:53 +0000 (UTC)
Organization: Mac GUI
Lines: 31
Message-ID: <marklim-1385173911@macgui.com>
References: <marklim-1383903408@macgui.com> <dog_cow-1384022046@macgui.com> <marklim-1384051053@macgui.com>
NNTP-Posting-Host: gunshin.wiredns.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: technocratmedia-w1.news.bbs-scene.org 1385173913 6198 74.119.145.48 (23 Nov 2013 02:31:53 GMT)
X-Complaints-To: abuse@bbs-scene.org
NNTP-Posting-Date: Sat, 23 Nov 2013 02:31:53 +0000 (UTC)
User-Agent: Mac GUI Usenet
Xref: csiph.com comp.sys.apple2.programmer:980

Hi,

After spending sometime looking at the various LZW programs on the Internet,
I think I have located the bug that prevents the ShrinkIt decompressor
method UnpackLZW() from decoding correctly.

Right at the top of the method DecompressorError
DecompressorShrinkIt::UnpackLZW() is the following code snippet:

          ................

	while (! putByteErr)
	{
		if (GotClearCode())
		{
			SetGotClearCode(false);			
			SetAtBit(0);					
			SetCurrentEntry(0x0101);

          ................

Commenting out the statement SetAtBit(0) allows an entire archived text file
to be decoded correctly.

However, the CRC of the uncompressed data (fCRC16.CRCword.crc) does not
tally with fOriginalCRC.

Regards.

Mark