Bugs in Unix version of ARC

Daniel J. Hazekamp djh at cci632.UUCP
Wed Dec 10 06:51:02 AEST 1986


In article <1600003 at 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



More information about the Comp.unix.questions mailing list