Баг в depacker от hrust1.3?

[Vitamin]

Мне, честно говоря, даже в голову не приходило, что можно попытаться распаковать блок с пересечением с упакованным файлом.
Имхо, в таком случае в распаковщик нужно добавить проверку - если в памяти достаточно места, то не делать копирование. Размер распаковщика, конечно, вырастет, но геморроя уменьшится.
С MegaLZ я не встречал такой ситуации ни разу - MegaLZ работает иначе или мне еще "повезет"?

Блин, да невозможно в общем случае это предвидеть!
Представь, что ты бежишь наперегонки с другим человеком. Причем у тебя фора, примерно в половину дистанции. Ты бежишь практически равномерно, а твой соперник- нет. Иногда бежит немного медленнее тебя, иногда быстрее на два порядка. В среднем- чуть быстрее. Но прийти к финишу раньше тебя не может.
Вот на основании таких данных скажи- обгонит ли твой соперник тебя в процессе движения?

[Shadow Maker]

С MegaLZ я не встречал такой ситуации ни разу - MegaLZ работает иначе или мне еще "повезет"?

Потому что он ничего никуда не перебрасывает. Типа "тебе надо - ты и перебрасывай, если надо". А Хруст пытается дать хоть какую-то возможность для распаковки с минимальными затратами памяти. Короче вот когда у тебя будет ситуация, что занята вся память и распаковать можно только поверх и запас у тебя там байтов 10 - тогда и "повезет"

[John North]

Ё-моё... ну ты хоть соображалку включи и представь что будет, если распаковывать в ту же память, где лежит упакованный оригинал.

Не понял меня никто..
Имелось в виду, что запакованный блок лежит, напр, по адресу 30000, а распаковать надо, напр, в 49152..

[Vitamin]

Имелось в виду, что запакованный блок лежит, напр, по адресу 30000, а распаковать надо, напр, в 49152..

1) Это совершенно не гарантирует, что перекрытия не будет
2) Требует усложнения процедуры генерации кодового блока с депакером

[jerri]

John North, в данном случае программа предполагает что длина блока может быть 20000 тогда еще нераспакованные данные вполне успешно убиваются данными распакованными
введение дополнительной проверки лишь усложняет код и увеличивает и так немаленький распаковщик

[Vitamin]

Как-то трудно мне представить что будет перекрытие в таком случае...

Упакованный блок длинее 19152 байта

[Advertiser]

[Vitamin]

ну это логично конечно, но вряд ли 16кб (максимум) удастся упаковать в 19152 байта

Вообще да. Согласно формату Hrust, абсолютно неупакованный блок размером 16384 байта займет на выходе 12+16378+16378/8=18437 байт.

[jerri]

вы это распаковщику обьясните в 3-4 байта

[Shadow Maker]

Как мне вот такой блок распаковать? Как до нулей перед самым концом доходит - лезут глюки, нули не кончаются - причем даже если в другой области памяти лежат исходные данные. Непонятно как побороть. Депакер чтоли особый какой надо?

[jerri]

Shadow Maker, по смещению #2236 находится набор нулей
а с адреса #2277 находится труднопакуемый кусок который успешно херит все

возьми депакер который ничего никуда не двигает