Обнаружение EOF с помощью ZLib Gzip API?

#c #gzip #zlib

Вопрос:

У меня есть примерный пример Gzip Compressed Data | 100-length RNG Pad . Удивительно, что zlib GZip file API способен обнаруживать EOF в начале блока длиной n и не учитывать его. Попробуйте Онлайн

Я попытался просмотреть заголовок и исходный код, и это были мои лучшие предположения:

На основе исходного кода — Обнаруживает повреждение потока из-за обнаружения недопустимой последовательности байтов — следовательно, gzread возвращает -1.
На основе заголовка файла — Обнаруживает CRC32 в конце во время последнего read и проверяет соответствующий размер файла после него. Если все совпадает, он возвращает EOF.

Может ли кто-нибудь подтвердить мое понимание того, что (1) действительно происходит. Если это так, я предполагаю, что пример, который я опробовал, может быть неопределенным поведением, основанным на последовательности случайных байтов.

Ответ №1:

Если вы спрашиваете о zlib, обнаруживающем, что он получает случайные данные, которые должны быть потоком gzip, то да, обычно это делается в пределах небольшого количества байтов на основе нарушений формата заголовка или формата deflate.

1. Спасибо, Марк. Таким образом, кажется, существует ничтожная вероятность того, что случайный поток байтов, объединенных в конце файла gzip, может не нарушать формат deflate, в свою очередь, не попадая в EOF и, следовательно, приведенный выше код завершится ошибкой?

2. Я не знаю, что вы подразумеваете под «сбой», поскольку я не знаю, каковы ваши требования. Существует ничтожно малая вероятность того, что случайные данные, заменяющие содержимое части потока gzip, по-прежнему будут выглядеть как действительный поток gzip, если данные deflate действительны, а CRC и длина в конце совпадают и все закончилось именно там, где ваши данные заканчивались изначально.