Распаковка zlib возвращает -5 в Ubuntu 10.10 x64 (g ++ -m64) - PullRequest
1 голос
/ 17 февраля 2011

Я использую python и zlib для сжатия буфера и распаковываю его в программе на C ++.

Если я собираю программу с помощью g ++ -m32, я могу распаковать буфер.

Если я собираю его с помощью g ++ -m64 (и связываю с тем же параметром), он возвращает -5 (Z_BUF_ERROR).

Можно это исправить? Должен ли я изменить размер моего буфера?

Я назначил свой выходной буфер с точным размером, я должен выровнять его по 64 битам или что-то еще?

Спасибо.

Ответы [ 2 ]

2 голосов
/ 17 февраля 2011

Я недавно столкнулся с такого рода проблемами.У нас было программное обеспечение, работающее нормально при компиляции в 32 бита (даже если оно работает на 64-битной системе), но возвращало тот же Z_BUF_ERROR из uncompress () при компиляции для 64-битной среды (используя -m64)

Сжатые данные былипроверил: прочитал из сжатого файла программным обеспечением, затем сбросил в файл снова и затем сравнил, никаких различий.

Таким образом, мой вывод состоял в том, что проблема исходила от самого zlib.Репозитории Ubuntu 10.4, кажется, предоставляют только zlib версии 1.2.3.Домашняя страница zlib предоставляет версию 1.2.5 (с некоторыми заметками о лучшей переносимости).

Надеюсь, это поможет.

edit: мы перешли от использования uncompress () к inflate () и исправилинаша проблема для 64-битной архитектуры.Мы до сих пор не знаем, работает ли uncompress () для 64-битных систем с более новой (> 1.2.3) версией zlib.Но этот обходной путь подходит для использования zlib-1.2.3 / 64bits.

1 голос
/ 26 июля 2014

У меня была такая же проблема. Это было потому, что я передавал ссылку на int как второй параметр uncompress (destLen). Это привело к неверному значению внутри функции распаковки из-за расширения до uLong (8 байт вместо 4). Использование ссылки на переменную uLong для параметра destLen решило все проблемы

...