baron@transys.UUCP (04/30/87)
In article <1296@ubc-cs.UUCP> brachman@ubc-cs.UUCP (Barry Brachman) writes: >In January, Robert Wilhite <wilhite@usceast.uucp> posted arc to net.sources. >While this version seems to work fine on the VAX, it >does not work on the Sun (try to create or add to an archive). I recently >spent a few hours looking at the code and found several bugs and quite a >bit of questionable coding. Lint yells alot too. In short, it is badly in >need of a rewrite. It's a miracle it runs on the VAX. >(To be fair, Robert is not the sole author.) I agree. I have been working on the sources to arc for a little while to get it to run under SCO Xenix on an IBM AT. It would seem to work fine as long as the archived members were all less than some magic size (around 64k), but gave all kinds of core dumps and funny messages if the size were larger. Turns out there is some code in the header reading and writing routines that tries to shift a long by 8, 16 and 24 bits respectively then ands the result with 255 to get a byte order independent representation of the size into the output file. The shift values of 16 and 24 return zero! I have changed this and now I can un- arc anything that comes through (so far). I can add items to an archive, but I can not crunch them (memory fault). I am working on this. There were also references to null pointers, and passing longs when you needed to pass an int. On a 286 under xenix passing the wrong parameter type is guaranteed to land you in bananaville. I only found this by examining the assembler output file, which showed the stack being misadjusted. This piece of software really puzzles me because the original ARC was for IBM PC's. If anyone wants the diffs to make it work (as well as it does now) e-mail & I will be happy to send them to you. Enough response will warrant a posting. The changes should be portable, as I used no shift instructions but used constant division and multiplication instead.