[net.sources.d] ARC for UNIX

sag2@ur-tut.UUCP (Dent Arthur Dent) (09/14/86)

A while ago I downloaded from the net a program that created archives 
compatible with ARC for the IBMPC.  I compiled it on a Pyramid but the
program either hung or core-dumped when run.  I then transferred it to
my account an a Vax 11-750 running Ultrix 1.2.  The program eventually
ran and created an archive readable by ARC on the IBMPC.  The only problem
I have found thus far is that when checking the CRC value, the program
on the Vax sometimes gives an 8-digit hex as opposed to a 4-digit hex
value.  Could this be from something left in the code that only works
correctly on MS-DOS like the "b" in the fopen() type parameter.

Note that the archive unarcs fine on both the Vax and the PC.  One segment
of code I am suspicious of is the bit operations used in arcadd():

   return ((crc>>8)&0x00ff) ^ crctab[(crc^c)&0x00ff];

where crc is an int an c is an unsigned char.  Since my memory of bit
operations is a bit unclear, what exactly is this supposed to do and
is there a way in which it can produce, for example a CRC of fffa301
on a Vax and a CRC for the same archive, same file of a301.  It appears
as though all errors are caused by the four high-order bits being
ffff on the Vax whereas on the PC there are no bits except the four bits
(by bits I really mean hexadecimal digits).

Please let me know via email what is going on here and when and if there
is going to be another post of an improved arc for UNIX.

-- Steven Grotten
uucp:	{seismo, allegra, decvax, cmcl2, topaz, harvard}!rochester!ur-tut!sag2
BITNET: sag2@UORVM
Physical:43 01' 40'' N, 77 37' 49'' W

-------------------------------------------------------------------- 
|                                                                  |
|  "I refuse to be murdered wearing a blue and white cone on my    |
|   head.  It is perfectly undignified."                           |
|                                                                  |
--------------------------------------------------------------------

spear@ihlpf.UUCP (Spearman) (10/09/86)

There is another problem with arc for unix I discovered while
running it on a UNIXPC.  The file arcunix.c contains a function
called xrealloc().  This procedure calls realloc.  Unfortunately,
since realloc was #defined to be xrealloc in arc.h, this causes
a recursive call indefinitely, resulting in process death from
lack of swap space (on the Unix PC anyway).  This occurs, for
example, whenever trying to add more than one file at a time
to the archive.

The fix is simple: #undef realloc 
put this right before the realloc call in xrealloc.  You may
also want to do something like: extern char * realloc
to avoid a warning message during compiling.

Steve Spearman  ihnp4!ihlpf!spear