Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mitel!sce!klink From: klink@sce.carleton.ca (Robert Klinkhammer) Newsgroups: comp.sys.ibm.pc Subject: Re: uncompress on PC - not there yet Summary: On second thoughts... Keywords: PC compress Message-ID: <717@sce.carleton.ca> Date: 22 Nov 89 05:46:11 GMT References: <824@dukempd.phy.duke.edu> <2565B872.3324@maccs.dcss.mcmaster.ca> <716@sce.carleton.ca> Organization: Systems & Computer Eng. Dept., Carleton University, Ottawa, Canada Lines: 32 Once again, posted for ...!uunet!mitel!sce!tsmith!graham After rereading the paper by Welch, and staring at the code for another couple of hours, I'm a bit more confident that the code is correct. I can think of at least 4 reasons that compress would complain about corrupt input: 1) The file really was corrupt. Did you look at the output generated by decompress on the SUN? It is possible that it would quietly decompress corrupt input. (Unless SUN have made enhancements) 2) The file got nuked while copying it to your PC. Did you use a binary file transfer mechanism. Was the size of the file the same on the PC as on the SUN? 3) The compiler that you used to compile compress is broken. Or it somehow managed to open the input file in text mode rather than binary mode. 4) I'm broken. > I would appreciate it, if you could send me a copy of the compressed > file that caused the trouble. (That is, if it's not too big) This is still holds, as I am quite concerned about point 4, and am anxious to disprove it. Doug. -- ********************************************************************** Robert Klinkhammer "They recommended euthanasia for noncomformists anywhere" -- Asia **********************************************************************