zlib uncompress 在 Ubuntu 10.10 x64 上返回 -5 (g++ -m64)
我使用 python 和 zlib 来压缩缓冲区，并在 C++ 程序中解压缩它。
如果我使用 g++ -m32 构建程序，我可以解压缩缓冲区。
如果我使用 g++ -m64 构建它（并使用相同的选项链接），它将返回 -5 (Z_BUF_ERROR)。
我可以修复它吗？我应该改变缓冲区的大小吗？
我分配了精确大小的输出缓冲区，我应该将其对齐 64 位还是其他什么？
谢谢。
I use python and zlib to compress a buffer, and I uncompress it in a C++ program.
If I build the program with g++ -m32, I can uncompress the buffer.
If I build it with g++ -m64 (and link with the same option), it returns -5 (Z_BUF_ERROR).
Can I fix it ? Should I change the size of my buffer ?
I allocate my output buffer with the exact size, should I align it on 64 bits or something ?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我最近遇到了这样的问题。我们有一个软件在 32 位编译时运行良好（即使在 64 位系统上运行），但在为 64 位环境编译时（使用 -m64）从 uncompress() 返回相同的 Z_BUF_ERROR
仔细检查了压缩数据：从压缩中读取文件由软件然后再次转储到文件中然后进行比较，没有差异。
所以我的结论是问题来自 zlib 本身。 Ubuntu 10.4 存储库似乎只提供 zlib 版本 1.2.3。
zlib 主页提供了 1.2.5 版本（带有一些关于更好的可移植性的注释）。
希望有帮助。
编辑：我们从使用 uncompress() 改为使用 inflate()，它解决了 64 位架构的问题。我们仍然不知道 uncompress() 是否适用于具有较新版本（>1.2.3）zlib 的 64 位系统。但如果使用 zlib-1.2.3 / 64 位，此解决方法是可以的。
I recently ran into this kind of problems. We had a software running fine when compiled in 32bits (even if run on a 64bits system) but returning the same Z_BUF_ERROR from uncompress() when compiling it for 64bits environment (using -m64)
The compressed data was carefully checked: read from a compressed file by the software then dumped in a file again and then compared, no differences.
So my conclusion was the problem was coming from the zlib itself. Ubuntu 10.4 repositories seem to only provide zlib version 1.2.3.
The zlib home page provides version 1.2.5 (with some notes about better portability).
Hope it helps.
edit: We moved from using uncompress() to inflate() and it fixed our problem for 64bits architecture. We still don't know if uncompress() is working for 64bits systems with newer (>1.2.3) version of zlib thus. But this workaround is ok if using zlib-1.2.3 / 64bits.
我也有同样的问题。这是因为我传递了对 int 的引用作为解压缩的第二个参数（ destLen ）。由于扩展到 uLong（8 个字节而不是 4 个字节），这导致解压缩函数内的值不正确。使用 uLong 变量引用作为 destLen 参数解决了所有问题
I had the same problem. It was because I was passing a reference to an int as second parameter of uncompress ( destLen ). This led to an incorrect value inside the uncompress function because of the expansion to uLong (8 bytes instead of 4). Using an uLong variable reference for the destLen parameter solved all problems