Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!djh From: djh@cci632.UUCP (Daniel J. Hazekamp) Newsgroups: comp.unix.questions,net.sources.bugs Subject: Re: Bugs in Unix version of ARC Message-ID: <737@cci632.UUCP> Date: Tue, 9-Dec-86 15:51:02 EST Article-I.D.: cci632.737 Posted: Tue Dec 9 15:51:02 1986 Date-Received: Wed, 10-Dec-86 04:03:51 EST Organization: CCI, Communications Systems Division, Rochester, NY Lines: 48 Keywords: ARC mode 6 Lempel Zev Xref: mnetor comp.unix.questions:295 net.sources.bugs:910 In article <1600003@fthood>, Emmet Gray writes: I just can't believe that everyone else's copy of 'arc' is running properly on UNIX. I've got the two versions off the of net, the one posted in mid Aug and the other in late Sep. Both seem to compile and function except for extracting files that have been compressed using one older 'crunch' routine (which is longer used in creating files, but is arround for extracting). The older archives created using method number 6 called "Lempel-Zev plus non-repeat" (shows up as 'crunched' in the 'v' option) will not extract properly. Small files appear to extract, but result in garbage files. Extracting large files created with this method will cause the arc's internal stack to overflow. Aside from that one minor problem, everything works! Has anyone else had this problem? Is there a cure? I'm running SVR2 on a Masscomp 68000 system. Emmet P. Gray US Army, HQ III Corps & Fort Hood ..!ihnp4!uiucuxc!fthood!egray Attn: AFZF-DE-ENV DEH, Environmental & Natural Resources Management Office Fort Hood, TX 76544-5057 I've also come across this problem, and have finally come up with the fix. The problem area is in the function oldh() in arclzw.c. The hash key must be truncated to 16 bits before it is squared. Since most ints on larger machines are 32 bits, the line 'local = (pred + foll) | 0x0800' doesn't work. Changing it to 'local = ((pred + foll) | 0x0800) & 0xFFFF' causes it to work properly. By the looks of the code in newh(), the problem may also arise with type 7 entries. I don't have any arc's with type 7 entries to test with, so if some kind soul could test it for me, I'd appreciate it. If the problem does arise, the fix is similar to that above. Truncate the sum of pred & foll to 16 bits before the multiplication: return (((pred + foll) & 0xFFFF) * 15073) & 0x0FFF; Dan Hazekamp Computer Consoles Inc. Rochester NY seismo!rochester!cci632!djh