jwp@larry.UUCP (Jeffrey W Percival) (02/21/89)
I am using the VMS/Unix compress software available on several archive sites, and am unable to decompress on UNix a file compressed on VMS. I am getting a "Stack Overflow" in the decompress routine. The file I am decompressing is only a few hundred bytes long, so obviously the code scanner is getting hosed up somewhere, I guess in a long loop caused by sign extension or something. Is that a very good guess? I've been twiddling various compiler flags, without success. Any thoughts? -- Jeff Percival (jwp@larry.sal.wisc.edu)
scs@adam.pika.mit.edu (Steve Summit) (02/22/89)
In article <522@larry.UUCP> jwp@larry.UUCP (Jeffrey W Percival) writes: >I am using the VMS/Unix compress software available on several archive >sites, and am unable to decompress on UNix a file compressed on VMS. >I am getting a "Stack Overflow" in the decompress routine. I had the same problem (same symptom, even) when bringing up compress under MS-DOS. I had forgotten to indicate that the file should be read in "binary" as opposed to "text" mode. (One of DOS'es innumerable misfeatures is that it makes this distinction.) The failure mode under DOS (which I didn't trace through, because setting binary mode made it go away immediately) would have been that a carriage return/line feed sequence (two characters) in the compressed file would have been seen by the decompress program as a single line feed. It's difficult to imagine how a Unix-based decompress could be bitten by this problem, unless: 1. the VMS compress used the wrong text vs. binary mode, or 2. the file was corrupted (CR/LF games) during the transfer from VMS to Unix (most likely). Did you use FTP? Did you remember to set binary mode? It seems that decompress should be more robust in the face of corrupted input (crashing with a stack overflow is fairly graceless), but the algorithm (with which I am unfamiliar) may make recovery difficult. Steve Summit scs@adam.pika.mit.edu