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