如果用lzo1x_decompress，则程序执行时，系统弹出错误对话框。如果是用lzo1x_decompress_safe的话，则该函数返回值总是-5，根据lzo文档的说明，也就是说“数据被破坏，或目标buffer的长度太短”。可是，我的lzo1x_decompress_safe函数的源buffer我就设了1K，而目标buffer的长度我设成256K，这样还嫌短啊！
后来实在扛不住了，打开LZO相关的源代码先看了一下，终于发现两个问题，现在想请教一下各位：
1. 我在试验我编写出来的函数的时候，是随便拿了个文件来解压缩的，结果出错，函数返回值为-5。我在想，我的源buffer和目标buffer的长度差距那么大，不太可能是目标buffer长度不够的问题，那就是数据被破坏，问题是它怎么晓得我的数据是被破坏的。所以想问下，象lzo1x_decompress这类解压缩函数，它所处理的数据，是不是不能为任意的数据的，是不是必须得是先前由lzo1x_compress函数处理过的压缩数据才行啊！这一点好象LZO的文档没有说明，我以为是可以处理任意数据的，现在出错，我怀疑是不是这方面出的问题。
2. 结果用那个函数来处理abc.src这类被压缩的函数，照样出错。这个问题的答案我在源代码里找到了线索。在lzo-2.03\src\lzo1.c这个文件中，我看到文件头有两处变量，是可以自定义的。分别是RBITS（3-5）和CLEVEL（1-9），这两个数据是用宏定义的，有注释说是可以自行更改以便于自定义，而对同一数据的压缩函数和解压函数必须使用相同的变量才行。我怀疑我的程序出错可能就在这两个变量上，那个abc.src在压缩的时候所采用的RBITS和CLEVEL和我的可能不一样。
原因我都自己想出来了，但是目前还没有上机实证，所以我还不确定我想的对不对，我先发上来，希望玩过lzo库的人能否指点一下我的猜测对不对。谢谢！
2 个解决方案
#1
该回复于2009-05-18 10:04:55被版主删除
#2
帮顶！！！
#1
该回复于2009-05-18 10:04:55被版主删除
#2
帮顶！！！